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^ (54) Title: SYSTEM AND METHOD FOR PROVIDING CERTIFICATE VALIDATION AND OTIfER SERVICES 

^ (57) Abstract: A system and method for facilitating clecu-onic commerce by securely providing certificaie-related and others ser- 
vices including certificate validation and warranty is disclosed. In a preferred embodiment, these services are provided within the 
context of a four-comer uusl model. The four-comer model comprises a buyer, or subscribing customer, and a seller, or relying 
^ customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution, or issuing participant. The is- 
^ suing participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate 
signed by the issuing participant. The seller is a customer of a second financial institution, or relying participant. The relying par- 
licipani operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed 
Q by the relying participant. The system also includes a root certificate authority that operates a certificate authority that issues digital 
^ certificates to the issuing and relying participants. At the time of a transaction, the buyer creates a hash of the transaction data, signs 
^ the hash, and transmits the u-ansaction data, the signature, and its digital certificate to the seller The seller may then request services. 
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System and Method for Providing Certificate Validation 
and Other Services 

This patent application claims priority jBrom United States provisional patent 
application serial No. 60/153,726, filed on September 13, 1999, entitled Transaction 
Coordinator for Certificate Status Checking and Other Services and United States provisional 
patent application serial No. 60/153,724, filed September 13, 1999, entitled Transaction 
Coordinator Requirements and High Level Design, both of which are hereby incorporated by 
reference. 

Field of the Invention 

This invention relates generally to the field of facilitating electronic commerce by 
providing services via a public key infrastructure. 

Background of the Invention 
The world of electronic commerce has created new challenges to establishing 
relationships between contracting parties. One of those challenges springs from the fact that 
the parties to the transaction cannot see or hear each other, and cannot otherwise easily 
confirm each other's identity and authority to act. 

One remedy for this problem is to provide each contracting party with a private key 
for signing transmitted messages. The signing party makes available an associated public 
key that decrypts messages signed widi the party's private key, and thus enables a receivmg 
party to confirm the identity of the sender. 

But the sender's public key may not be known a priori to the recipient. In that event, 
the sender may transmit with its signed message a digital certificate issued by a certificate 
authority. The certificate is itself a signed electronic document (signed wdth the private key 
of the certificate authority) certifying that a particular public key is the public key of the 
sender. 

In some cases, the recipient may be unfamiliar with the public key of the certificate 
authority or may not know whether the certificate is still valid. In that event, the recipient 
may wish to check the authenticity and validity of the certificate with an entity that it trusts. 
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One known protocol for checking certificate status is the on-line certificate status protocol 
(OCSP). 

5 Summary of the Invention 

A system and method are disclosed for facilitating electronic conomerce by securely 
providing certificate-related and other services including certificate validation and warranty. 
In a preferred embodiment, these services are provided within the context of a four-comer 
trust model. The four-comer model comprises a buyer, referred to as the subscribing 

10 customer, and a seller, referred to as the relying customer, who engage in an on-line 

transaction. The buyer is a customer of a first financial institution, referred to as an issuing 
participant. Hie issuing participant acts as a certificate authority for the buyer and issues the 
buyer a hardware token including a private key and a digital certificate signed by the issuing 
participant. The seller is a customer of a second financial institution, referred to as the 

1 5 relying participant. The relying participant acts as a certificate authority for the seller and 
issues the buyer a hardware token including a private key and a digital certificate signed by 
the relying participant. The system also includes a root certificate authority that issues digital 
certificates to the issuing and relying participants. 

At the time of a transaction, the buyer creates a hash of the transaction data, signs the 

20 hash, and transmits the transaction data, the signature, and its digital c^tificate to the seller. 

The seller may then request system services via a connection with its financial institution, the 
relying participant. 

In a preferred embodiment, these system services may include a certificate status 
check service and a warranty service. The certificate status check service allows the relying 
25 customer to validate the subscribing customer's certificate. The warranty service allows the 
rel}ang customer to receive a collateral-backed warranty that the subscribing customer's 
certificate is valid. Detailed message flows for providing these services are provided in the 
detailed description. 

In a preferred embodiment, each participant and the root entity is provided with a 
30 transaction coordinator for combining services and operations into a single transaction having 
the qualities of atomicity, consistency, isolation, and durability. The transaction coordinator 
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provides a single consistent interface for certificate-status messages and requests, as well as 
messages and requests relating to other services. As a result, the present invention provides 
the necessary flexibility to permit centralized and consistent capture of transactional 
information relating to a plurality of offered services for audit and non-repudiation puiposes. 
5 In addition, the present invention facilitates the integration of additional services and 
provision of those services to customers. 

The disclosed transaction coordinator provides a single interface to facilitate 
electronic communications amongst banks or other financial institutions or between banks or 
other financial institutions and their customers. The transaction coordinator also provides a 
1 0 single entry point for customers to obtain certificate-check services and provides the 
flexibility to add new business application services, such as warranty service, payment 
guarantee service, or certified mail service, while stUl providing a single entry point for these 
additional services. It is preferably designed to be easily extended to support additional 
services as they are created. 
^ ^ The disclosed transaction coordinator provides parsing, flow control, and error 

handling for the present messaging infrastructure and acts as a message switch to route 
message components to an appropriate system service (e.g., to an OCSP responder, warranty 
engine, etc.). In addition, it collates responses firom these services into a consolidated 
response and dispatches the responses to requesting clients. 
20 The disclosed transaction coordinator also records billing data for the certificate 

check service or other services in a centralized general fashion. Because all of the banks and 
other financial institutions have their own requirements for biUing, the billing data can be 
extracted and modified to an individual financial institution's needs by writing simple 
extraction functions. 

2^ The disclosed transaction coordinator also allows banks or other financial institutions 

to cross-charge each other for different types of transactions as needed. Further, the 
disclosed transaction coordinator allows for the integration of commercial off-the-shelf 
software applications and provides a single electronic signing service to electronically sign 
and verify documents. 

In addition, the disclosed transaction coordinator isolates all core services, thereby 
promoting reuse of components and simplifying the maintenance and enhancements of these 
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services. The disclosed transaction coordinator does not require changing the on-line 
certification check functionality that would render it non-standard and might result in vendor 
locking and implementation delays. 



5 Brief Description of the Drawin^^s 

These and other objects, features, and advantages of the present invention will be 
better understood when taken m conjunction with the following detailed description and 
accompanying drawings in which: 

Fig. 1 is a block diagram of a preferred embodiment of the four-comer model 
1 0 employed by the present system; 

Fig. 2 is a block diagram depicting components preferably provided at entities in the 
four-comer model; 

Fig. 3 is a block diagram of a preferred embodiment of a transaction coordinator; 

Fig. 4 is a composite block/flow diagram that demonstrates certain aspects of 
1 5 transaction coordinator operation in a preferred embodiment; 

Fig. 5 is a composite block/flow diagram depicting preferred operation of the signing 
component of a transaction coordinator. 

Fig. 6 is a composite block/flow diagram demonstrating a preferred embodiment of 
the steps performed by a transaction coordinator in performing a certificate status check; 
20 Fig. 7 is a composite block/flow diagram illustrating a preferred embodiment of the 

transaction flow for validating a certificate; 

Fig. 8 is a composite block/flow diagram illustrating the transaction flow for one 
preferred embodiment of a warranty service; 

Fig. 9 is a composite block/flow diagram of a preferred embodiment of server-side 
25 authentication; 

Fig. 10 is a composite block/flow diagram of a preferred embodiment of client-side 
authentication; 

Fig. 1 1 is a composite block/flow diagram illustrating a preferred message 
authentication process; 

30 Fig. 12 is a composite block/flow diagram of a preferred embodiment of the security- 

relevant flows associated with components of a transaction coordinator; 
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Fig. 14 is a composite block/flow diagram that depicts tne 
OCSP-proxT centric embodiment of the present system. 
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Fig. 2 is a block diagram depicting components preferably provided at entities in the 
four-comer model. As shown in Fig- 2, participants 102, 104 and root entity 110 are each 
provided with a transaction coordinator 202 that serves as a gateway for transmitting and 
receiving all inter-entity messages related to services provided by the present system. As 
5 described in more detail below, transaction coordinators 202 provide a single interface to 
issuing participant 102's and relying participant 104's on-line services, and implement 
safeguards necessary to ensure secure electronic communications between transaction 
coordinators 202 and other entities in the four-comer model. One preferred embodiment of a 
transaction coordinator 202 is described below in connection with Figs. 3-6. 

10 Participants 102, 104 and root entity 110 are each further preferably provided with an 

OCSP responder 204 and hardware security module (HSM) 206. Exemplary requirements 
for an OCSP responder 204 are described below. HSM 206 is adapted to sign messages and 
verify signatures on messages, as described below, in connection with Fig. 6. 

In addition, each participant 102, 104 and root entity 1 10 is further preferably 

15 provided with a billing data database 208 (connected to a bank billing application 21 0 in the 
case of participants 102, 104), a raw transaction log, 212, a customer data database 214, a 
risk manager 216 (connected to customer data database 214), and a second hardware secvirity 
module 218, each of which is connected to transaction coordinator 202. 

As further shown in Fig. 2, relying customer 108 is preferably provided with a Web 

20 server 220 that is adapted to receive and transmit information via the Intemet Reljdng 

customer 108 is further preferably provided with a bank interface 222 for communicating 
with relying participant 104, as described in more detail below. One preferred embodiment 
of bank interface 222 (as well as additional components preferably provided at the relying 
customer) is described in copending United States patent application serial No. 

25 , filed on even date herewith, entitled System and Method for Facilitating 

Access By Sellers to Certificate-Related and Other Services, which is hereby incorporated by 
reference. Relying customer 108 is preferably further provided with a hardware security 
module 230 for signing and verifying system messages. 

As fiirther shown in Fig. 2, subscribing customer 106 is preferably provided with a 

30 Web browser 224 for browsing the hitemet and a smart card 226 (and associated reader) for 
signing digital messages, as described below. 

-6- 
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In a preferred embodiment, each system entity is provided with two digital 
certificates (and corresponding private keys) to facilitate authentication: An identity 
certificate (also referred to, in some cases, as a warranty certificate) and a utility certificate. 
In addition, in a preferred embodiment, each transaction coordinator 202 is preferably 
provided with its own identity certificate and utility certificate and associated private keys. 

The identity private key is used to produce digital signatures that are required by root 
entity 110 as evidence of an entity's contractual commitment to the contents of an electronic 
transaction. A certificate chain is needed to support operations using this key. The status of 
the identity certificate may be obtained by authorized entities, as described below. 

The utility private key is used to produce digital signatures that allow additional 
transactional security. Typically, utility certificates are used to support secure socket layer 
sessions, to sign S/MIME messages, and for other utility applications. A certificate chain is 
also needed to support operations using the utility key. The status of the utility certificate, 
however, may not be available to a requestor. Throughout this document, the term 
"certificate" refers to an identity certificate unless otherwise stated. 

In aprefenred embodiment, subscribing customer 106's digital certificates and 
associated private keys are provided to it by issuing participant 102. Issuing participant 102 
preferably issues smart cards or other suitable instruments to subscribing customer 106 that 
include at least the private key associated with the subscribing customer's identity certificate. 
If desired, the smart card may also include the subscribing customer's identity certificate. 
Preferred specifications for the smart card, its manufacture, and contents are described in 

copending United States provisional patent application serial No. , filed 

August 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance 
Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which 
is hereby incorporated by reference. 

Fig. 3 is a block diagram of a preferred embodiment of a transaction coordinator 202. 
As shown in Fig. 3, transaction coordinator 202 preferably comprises an interface 302 
comprising two components: a TC request manager 304 and a transport services component 
306. Interface 302 passes communications to and fi-om a plurality of service modules 308 
and core components 310. Service modules 308 preferably include a certificate status check 
module 312, warranty service module 314, apayment guarantee module 316, and may 
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comprise other service modules 318 for providing additional services. Core components 310 
preferably include a logging component 320, a billing component 322, and a signing 
component 324. 

Transport services component 306 provides a single entry point into the transaction 
coordinator and acts as an isolation layer between a requestor and the transaction 
coordinator's service modules and core components. Request manager 304 receives service 
requests from transport services component 306 and forwards them to appropriate service 
modules and/or core components, as described in more detail below. 

The function of certificate status check service 312 is to validate tiie certificates of 
entities within system 200 of Fig. 2. The fimction of warranty service 314 is to guarantee the 
identity of an entity that signs an electronic communication relating to a particular business 
transaction. In a preferred embodiment, the participant providing the warranty, typically 
issuing participant 102, accepts financial responsibility for some or all of the transaction 
amount if it is later discovered that subscribing customer 106 did not execute a digital 
signature created with the subscribing customer's private key. 

The fimction of payment guarantee service 3 16 is to further decrease the risk 
associated with a transaction by providing relying customer 108 with immediate 
confirmation of subscribing customer 106*s ability to fiilfiU a financial obligation. In 
addition, issuing participant 102 may issue a payment guarantee for some or all of the 
transaction amoimt if for some reason subscribing customer 106 fails to pay relying customer 
108. Payment services may also be established as described in copending United States 

patent application serial No. , filed on even date herewith, entitled System 

and Method for Providing Payment Services in Electronic Commerce, which is hereby 
incorporated by reference. 

The fimction of certified mail service 3 1 8 is to support ofiF-line transactions. Off-line 
transactions occur when the receiving entity, instead of servicing the request immediately, 
puts the request in a processing queue. Typically, an acknowledgment of receipt is sent to 
the requestor. This scenario may preferably be implemented when the transaction volimies 
are so large that it is not feasible to provide on-line responses to every request. Certified 
mail service 318 may preferably be used to satisfy requests between relying customer 108 
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and relying participant 104, relying participant 104 and issuing participant 102, and any 
request made to root entity 110. 

The function of logging component 320 is to log all service requests and OCSP 
responses in a raw transaction log 58 (see Fig. 5) for non-repudiation and security auditing 
purposes. 

The function of billing component 322 is to create and store a transaction billing 
history for messages (responses and requests) received by transaction coordinator 202. 
Preferred operation of these modules and components is further described below. 

Fig. 4 is a comi>osite block/flow diagram that demonstrates certain aspects of 
transaction coordinator operation in a preferred embodiment As shown in Fig. 4, in step 
4002, transport services component 306 of transaction coordinator 202 receives a service 
request from another system entity and sends the service request to request manager 304. In 
step 4004, request manager 304 checks to see if the service request format is valid. If the 
service request format is valid, request manager 304 requests information on the requestor, 
the billing data, and the service request type by calling a message validation module 404. 
Message validation module 404 calls a parser component 406 to extract the relevant 
information from the raw service request. 

In step 4006, request manager 304 calls an authentication module 408 to authenticate 
the requestor. Authentication module 408 is described in more detail below. 

In step 4008, authentication module 408 authenticates the requestor by calling signing 
component 324 of transaction coordinator 202 which, in turn, calls hardware security module 
218. A preferred structure and operation for signing component 324 is described in more 
detail below. 

In step 4010, authentication module 408 calls certificate status check component 414 
that in turn calls an OCSP responder 204 to perform a certificate status check on the 
requestor. A preferred structure and operation for certificate status check component 414 is 
described in more detail below. 

In step 4012, authentication module 408 calls a customer authorization check module 
41 8 to verify that the requestor is authorized to place the service request. A prefeixed 
stracture and operation for customer authorization check module 41 8 is described in more 
detail below. 
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In step 6002. certifloate check service module 312 leceives an mpatsed c«tificate status 
d^k request ftom service router 426 and forwards it to a parser component 406 4a. e^ 
the relevant customer information (comprising tl,e certificate to be checked) fix>m the 
re<naest In step 6004, certificate check service module 3 1 2 obtains any additional serv.ee- 

specifio ftffillment information ftom a customer database 606. 

In stq> 6006, if the certificate to be checked belongs to a customer of the pardcpant 

vvhose faction coordinator 202 received fte r«,uest. certificate check service module 3 1 2 

hands the request off to a local^omer handler 602. Otherwise, certificate check service 

module 312 hands the request off to a non-local-customer handler 610. 

In those cases where local-customer handler 602 handles the request, the system 

pn>ceeds to step 6008. where local customer handler 602 sendsacertificate check request to 

acertificate status check component 312. Certificate status check component 312 then 
obtains a certificate stams for the certificate to be checked fi»m its associated OCSP 
responder 204 (Le., the OCSP responder 204 belonging to the same transaction coordmator 
202 as certificate status check component 312). Flow in these cases then contmues with step 

6032 below. 

to contrast, in those cases where the certificate to be checked does not belong to a 
customer of the participant who received the request. fl.en, in step 6010. non-local-customer 
handler6101ooks uptime IP address of ate issuing participant that issued the certificate that ,s 

the subject of the request in a static DNS table 604. Tran^on coordinator 202„ .s 
preferably adapted to use the AIA extension in a certificate to idenfiiy the location of issumg 
participant 102. to step 6012. non-local.«.stomer handler 610 forwards the subject 
certificate to an OCSP request formulation module 608. In step 6014. OCSP request 
formulation module 608 formulates an OCSP request for the certificate and sends the request 
to signing component 324 for signature, to step 601 6, signing component 324 returns the 
signed request 

In step 6018. OCSP request formulation module 608 sends the signed request to the 
issuing participant 102 that issued the subject certificate. In step 6020, that issuing 
participant 1 02 returns an OCSP response to the request to OCSP request formulation 
module 608. 



wo 01/020513 



PCT/USOO/24662 



In Step 6022, OCSP request formulation module 608 forwards the response to 
non-local-customer handler 610. In step 6024, non-local-customer handler 610 logs the raw 
response data to raw transaction log 212 for non-repudiation puiposes. 

In step 6026, non-local-customer handler 610 sends the raw response data to parser 
5 component 406 to extract the certificates of issuing participant 1 02 and its transaction 
coordinator 202ip from the response. 

In step 6028, non-local-customer handler 610 validates the issuing participant's 
transaction coordinator certificate by repeating steps 6012-6024 but transmitting the OCSP 
request created in step 6014 to root entity 110 rather than issuing participant 102. 
1 0 Similarly, in step 6030, non-local-customer handler 610 validates the issuing 

participant's certificate by repeating steps 6012-6024 but transmitting the OCSP request 
created in step 6014 to root entity 110 rather than issuing participant 102. 

In step 6032, the certification check response data received by non-local-customer 
handler 610 or generated by local-customer handler 602 is sent to signing component 324 
1 5 which signs the response. In step 6034, the signed response is sent back to certifi^cate check 
service module 312 which, in turn, transmits the response to service request router 426. 

Fig. 7 is a composite block/flow diagram illustrating a preferred embodiment of 
transaction flow within system 200 for validating a certificate. As shown in Fig. 7, in step 
7002, subscribing customer 106 creates a hash of data representing a transaction between 
20 subscribing customer 106 and relying customer 108 and sends the hash to smart card 226 for 
signature. In step 7004, smart card 226 signs the data and returns the signed data along with 
the certificate of subscribing customer 106 and issuing participant 1 02. 

In step 7006, subscribing customer 106 sends the signed data and ihc two certificates 
to relying customer 108. In step 7008, relying customer 108 verifies the signature on the 
25 data sent by subscribing customer 106. This verification preferably includes checking the 
validity period of the received certificates. Alternatively, verification may be provided as a 
service to relying customer 108 by relying participant 104. Relying customer 108 then 
creates an OSCP request containing the subscribing customer's and issuing participant's 
certificates and transmits the request to hardware security module 230 for signature. In step 
30 7010, hardware security module 230 returns the signed request. 
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In step 7012, relying customer 108 transmits the signed OCSP request to relying 
participant 104, along with its own certificate. In step 7014, transaction coordinator 202rp of 
relying participant 104 receives the signed OCSP request and checks customer database 
214rp to make svire that the request was signed by an existing relying customer before 
processing the request In a preferred embodiment, a relying participant 104 does not 
process requests received firom a customer of a different participant In step 7016, 
transaction coordinator 202rp stores the raw transaction data (i.e., the unparsed request, 
signature, and accompanying relying customer certificate) in raw transaction log 212rp. In 
step 7018, any billing data necessary to appropriately bUl for services provided is stored in 
billing log 208rp. Alternatively, billing data may be extracted from the raw-transaction log 
by an off-line process to increase system performance. 

In step 7020, transaction coordinator 202rp verifies the relying customer's signature 
on the service request using the relying customer's certificate, the relying participant's 
certificate, and the root public key. The relying participant's certificate and the root public 
key may preferably be stored in hardware security module 21 8rp. 

In step 7022, transaction coordinator 202rp generates an OCSP request containing the 
relying customer's certificate, signs it, and sends it to its OSCP responder 204. 
Alternatively, if the transaction coordinator and OCSP responder are co-located, a signature 
on the request may not be necessary. In step 7024, OCSP responder 204 verifies the 
signature of the request, checks its local repository to determine the validity of its relying 
customer's certificate, and sends a response back concerning that certificate's status to 
transaction coordinator 202rp. 

It should be noted that, as part of system operation, relying customers 108 will often 
need to vaUdate the certificate of a subscribing customer 106 that is a customer of a 
participant other than relying participant 104. Because, in that case, relying participant 104 
is not the issuing participant that issued the certificate to be validated, it does not have first 
hand knowledge of that certificate's status. 

In a preferred embodiment, the present system addresses this problem by having each 
participant that receives an OCSP request for a certificate issued by another participant, 
forward the request to the issuing participant for that certificate. In particular in st^ 7026, 
relying participant 104 determmes the subscribing customer's issuing participant If the 
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subscribing customer is a customer of a different participant, relying participant 1 04 
generates a signed v£iiidation request for the subscribing customer's certificate and sends it to 
the identified issuing participant 102 along with its own certificate. Altematively, rather than 
sign the validation request, the relying participant may instead provide client-side 
5 authentication to issuing participant 102 as, for example, in the OCSP-proxy centric model 
described below. 

If the subscribing customer and the relying customer are both customers of the same 
participant, validation of the subscribing customer's certificate is handled by local-handler 
module 602, as described above. 

10 In step 7028, issuing participant 102 checks its customer database 214ip to make sure 

that the request was signed by an entity authorized to make the request. In step 7030, issuing 
participant 102 stores the received raw transaction (i.e., the unparsed request, signature, and 
accompanying certificate) in its raw transaction log 212ip. In step 7032, issuing participant 
102 stores relevant billing data for the request in its billing log 208. Alternatively, billing 

1 5 data may be extracted from the raw-transaction log by an off-line process to increase system 
performance. 

In step 7034, issuing participant 102 verifies transaction coordinator 202rp's signature 
on the request using the relying participant's transaction coordinator certificate (sent with the 
request) and the root public key (which may be stored in hardware security module 21 8|p). 
20 In step 7036, the issuing participant's transaction coordinator 202ip generates a signed OCSP 
request for the relying participant's transaction coordinator certificate and sends the request 
to root entity 110. 

In step 7038, transaction coordinator 202r of root entity 110 receives the request and 
stores the raw request in its raw transaction log 212r. In step 7040, transaction coordinator 

25 202r stores billing data for the request in billing data log 208r. In step 7042, transaction 
coordinator 202r verifies the signature on the request and then sends the request to OCSP 
responder 204r. In step 7044, CK!SP responder 204r checks its local repository to determine 
the status of the subject certificate and sends a response back concerning its status to 
transaction coordinator 202r. In step 7046, transaction coordinator 202r sends a signed 

30 response to transaction coordinator 202ip indicating the status of the relying participant's 
transaction coordinator certificate. 
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In step 7048, transaction coordinator 202ip of issuing participant 102 stores the OCSP 
response from root entity 110 in raw transaction log 212ip for non-repudiation purposes. In 
step 7050, transaction coordinator 202ip generates an OCSP request for the subscribing 
customer's certificate, signs it, and sends it to its own local OCSP responder 204ip along with 
its own certificate. Alternatively, if transaction coordinator 202n. and OCSP responder 204ip 
are co-located, a signature on the request may not be necessary. Also, if the two are co- 
located, the transaction coordinator may simply act as a pass through, as opposed to re- 
signing requests and responses. 

In step 7052, OCSP responder 204n. verifies the signature on the request, generates a 
response, signs it, and returns the signed response to transaction coordinator 202ip. In step 
7054, transaction coordinator 202n. verifies the OCSP responder's signature, resigns the 
response, and returns it to transaction coordinator 202rp along with its own certificate. 

In step 7056, transaction coordinator 202rp of relying participant 104 stores the raw 
response data received from issuing participant 102 in raw transaction log 212rp for 
non-repudiation purposes. In step 7058, transaction coordinator 202rp verifies the signature 
of transaction coordinator 202jp on the response using the issuing participant's transaction 
coordinator certificate (sent with the request) and the root public key (which may be stored in 
hardware security module 218rp). In step 7060, transaction coordinator 202rp generates a 
signed OCSP request for the issuing participant's transaction coordinator certificate and 
sends it to root entity 1 10. 

In step 7062, transaction coordinator 202r of root entity 1 10 stores the raw request 
data in raw transaction log 212r. In step 7064, transaction coordinator 202r stores relevant 
billing data in billing log 208r. In step 7066, transaction coordinator 202r verifies the 
signature on the request and sends the request to OCSP responder 204r. In step 7068, OCSP 
responder 204r checks its local repository to determine the status of the issuing participant's 
transaction coordinator certificate and sends a response back concerning its status to 
transaction coordinator 202r. In step 7070, transaction coordinator 202r sends a signed 
response concerning the status of the subject certificate to transaction coordinator 202rp. 

In step 7072, transaction coordinator 202rp of relying participant 104 stores the 
response in raw transaction log 212rp for non-repudiation purposes. At this point, processing 
of the subscribing customer's certificate is complete. 
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In Step 7074, transaction coordinator 202rp now processes the second half of the 
request: the issuing participant's certificate, by generating a signed OCSP request for the 
issuing participant's certificate and sending it to root entity 110. 

In step 7076, transaction coordinator 202r of root entity 1 10 stores the raw request 
5 data in raw transaction log 212. In step 7078, transaction coordinator 202r stores relevant 
billing data in billing log 208. 

In step 7080, transaction coordinator 202r verifies the signature on the request and 
sends the request to OCSP responder 204r. In step 7082, OCSP responder 204r checks its 
local repository to determine the status of the subject certificate and sends a response back to 

10 transaction coordinator 202r. In step 7084, transaction coordinator 202r sends a signed 
response to transaction coordinator 202rp. 

In step 7086, transaction coordinator 202rp of relying participant 104 stores the 
response from root entity 1 10 in raw transaction log 212rp for non-repudiation purposes. In 
step 7088, transaction coordinator 202rp creates an OCSP response firom the responses 

1 5 received firom transaction coordinator 202ip of issuing participant 102 and its local cache, 
signs it, and sends it to relying customer 108 along with its own certificate. 

In step 7090, relying customer 108 verifies the response using the root's public key 
certificate stored in hardware security module 230. In step 7092, relying customer 108 sends 
a request to transaction coordinator 202rp for the relying participant's transaction coordinator 

20 certificate in order to determine if that certificate has been revoked. In step 7094, transaction 
coordinator 202rp verifies the signature on the request and sends a request to local OCSP 
responder 204rp to ensure that the relying customer's transaction coordinator certificate has 
not been revoked. In step 7096, local OCSP responder 204rp responds to this request from 
transaction coordinator 202kp. 

25 In step 7098, transaction coordinator 202kp sends an OCSP request for the relying 

participant's transaction coordinator certificate to transaction coordinator 202r of root entity 
1 10. In step 7100, transaction coordinator 202r verifies the signature on the request and 
checks with local OCSP responder 204r to determine the status of the relying participant's 
transaction coordinator certificate. In step 7102, transaction coordinator 202r forwards the 

30 response received from local OCSP responder 204r to transaction coordinator 202rp. 
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In Step 7104, transaction coordinator 202rp forwards the response received from root 
entity 1 10 to relying customer 108. In step 7106, relying customer 108 provides 
acknovy^ledgment to subscribing customer 106. 

In connection with steps 7092-7104 above, it should be noted that, as part of system 
operation, relying customers 108 wdll typically need to obtain the status of relying participant 
1 04's transaction coordinator certificate. Within the four-comer model, the transaction 
coordinator and OCSP responder certificates of issuing participant 102 and relying 
participant 104 are signed by root entity 110. While root entity 110 operates an OCSP 
responder, this service is accessible only to participants. Consequently, relying customer 108 
cannot request validation of its relying participant's certificates directly from root entity 110. 

In a preferred embodiment, the present system addresses this problem by having each 
participant 102, 104 operate a root responder proxy. This proxy accepts requests from 
customers on behalf of the root, typically through a different uniform resource locator, 
forwards the request to the root over an authenticated secure sockets layer channel, and 
retums the response (still signed by the root) to tlie requesting party. 

The four-comer model described above may also be used to provide a warranty 
service that warranties the identity of a particular entity (e.g., the subscribing customer) that 
signed a transaction. One embodiment for providing such a warranty service is described 
below. Additional embodiments for providing warranty services are described in copending 

United States provisional patent application serial No. , filed August 14, 

2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, 
Warranty Service Functional Requirements, and Additional Disclosure, which is hereby 
incorporated by reference. 

Fig. 8 is a diagram of the transaction flow for one preferred embodiment of a 
warranty service. As shown in Fig. 8, in step 8002, subscribing customer 106 creates a hash 
of date representing a transaction between subscribing customer 106 and relying customer 
108 and sends the hash to smart card 226 for signature. In step 8004, smart card 226 signs 
the data and retums the signature along with the subscribing customer's certificate and the 
issuing participant's certificate. Optionally, this message may also include card and 
signature security data (CSSD) to inject additional security such as protection against 
duplicate messages. 
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In Step 8006, subscribing customer 106 sends the signed data, the signature, the 
subscribing customer's certificate, and the issuing participant's certificate (and optionally the 
CSSD) to relying customer 108. In step 8008, relying customer 108 verifies the signature on 
the data sent by subscribing customer 106. Alternatively, verification may be provided as a 
5 service to relying customer 108 by relying participant 104. Relying customer 108 then 
creates a warranty request and transmits the request to hardware security module 230 for 
signature. In step 8010, hardware security module 230 returns the signed request along with 
a copy of the relying customer's certificate. 

In step 8012, relying customer 108 sends the signed warranty request and relying 

1 0 customer certificate to relying participant 1 04. 

In step 8014, transaction coordinator 202rp of relying participant 104 checks 
customer database 214|yp to make sure that the request was signed by an existing customer 
before processing the request. In step 8016, transaction coordinator 202rp stores the raw 
transaction data relating to the transaction (i.e., the "unparsed" request, signature, and 

1 5 accompanying certificate) in raw transaction log 2 1 2^, In step 80 1 8, transaction coordinator 
202rp stores relevant billing data in billing log 208rp. Alternatively, billing data may be 
extracted fi*om the raw transaction log by an off-line process to increase system performance. 

In step 8020, transaction coordinator 202rp verifies the relying customer's signature 
on the request using the relying customer's certificate (sent with the request), the relying 

20 participant's certificate, and the root public key (both of which may be stored in hardware 
security module 218rp). Transaction coordinator 202^ then generates an OCSP request 
containing the relying customer's certificate, signs it, and sends it to its local OCSP 
responder 204rp. Alternatively, if the transaction coordinator and OCSP responder are co- 
located, a signature on the request may not be necessary. 

25 In step 8022, OCSP responder 204rp verifies the signature on the request, check its 

local repository for the status of the relying customer's certificate, and sends a response 
concerning that status back to transaction coordinator 202kp. 

In step 8024, transaction coordinator 202rp calls a risk manager 216rp to determine if 
relying customer 108 is financially authorized to make the warranty request. If it is, then, in 

30 step 8026, transaction coordinator 202rp determines the participant responsible for 

responding to warranty requests concerning subscribing customer 106 (i.e., the participant of 
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which subscribing customer 106 is a customer). In the present example, this entity is issuing 
participant 102. Transaction coordinator 202rp then creates a warranty request for 
subscribing customer 106, signs it, and sends it to issuing participant 102 along with its own 
certificate. It should be noted that if the relying customer and subscribing customer are both 
customers of the same participant, the warranty request may instead be processed locally by 
the participant. 

In step 8028, transaction coordinator 202ip checks customer database 214ip to make 
sure that the request was signed by an entity authorized to make the request. In step 8030, 
transaction coordinator 202n> stores the raw transaction data (i.e., the "unparsed*' request, 
signature, and accompanying certificate) in raw transaction log 212ip. In step 8032, 
transaction coordinator 202ip stores relevant billing data for the request in the billing log 
208ip. Altematively, billing data may be extracted fi-om the raw transaction log by an off- 
line process to increase system efficiency. In step 8034, transaction coordinator 202ip 
verifies transaction coordinator 202rp's signature on the request using transaction coordinator 
202rp's certificate (sent with the request), and the root public key (which may be stored in 
hardware security module 218ip). Transaction coordinator 202n. then generates a signed 
OCSP request for the relying participant's transaction coordinator certificate and sends it to 
root entity 110. 

In step 8036, transaction coordinator 202r of root entity 110 stores the raw request in 
raw transaction log 212r. In step 8038, transaction coordinator 202r stores relevant billing 
data for the request in billing data log 208r. In step 8040, transaction coordinator 202r 
verifies the signature on the request and then sends the request to OCSP responder 204r. 
OCSP responder 204r checks its local repository to determine the status of relying 
participant's transaction coordinator certificate and sends a response concerning that status 
back to transaction coordinator 202r. Transaction coordinator 202r then sends a signed 
response back to transaction coordinator 202ip. 

In step 8042, transaction coordinator 202ip of issuing participant 102 stores the raw 
response in raw transaction log 212ip for non-repudiation purposes. In step 8044, transaction 
coordinator 202ip then generates an OCSP request fi-om the request it received containing the 
subscribing customer's certificate, signs it, and sends it to its local OCSP responder 204|p 
along with its own certificate. Altematively, if the transaction coordinator and OCSP 
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responder are co-located, as signature on the request may not be necessary. Also, if the two 
are co-located, the transaction coordinator may simply act as a pass through as opposed to re- 
signing requests or responses. 

In step 8046, OCSP responder 204ip verifies the signature on the request, generates a 
5 response, signs it, and returns the signed response to transaction coordinator 202ip. In step 
8048, transaction coordinator 202ip calls risk manager 216n> to determine whether or not to 
issue a warranty for subscribmg customer 106. In step 8050, risk manager 21 6n. returns a 
signed message to transaction coordinator 202ip indicating whether a warranty should be 
issued. In step 8052, transaction coordinator 202ip stores the signed response in raw 
1 0 transaction log 2 1 2]p. 

In step 8054, transaction coordinator 202ip sends a signed request to transaction 
coordinator 202r of root entity 1 10 to determine if issuing participant 102 has enough 
collateral to issue the warranty. In step 8056, transaction coordinator 202r interacts with risk 
manager 216r to determine if issuing participant 102 is adequately collateralized and, if so, 
1 5 decreases issuing participant 1 02's collateral level by an amount appropriate for the warranty 
being issued and returns a response to issuing participant 102. 

In step 8058, transaction coordinator 202ip verifies transaction coordinator 202r's 
signature, creates a warranty response, and returns it to transaction coordinator 202rp along 
with its certificate. 

20 In step 8060, transaction coordinator 202rp of relying participant 1 04 stores the raw 

response in raw transaction log 212rp for non-repudiation purposes. In step 862, transaction 
coordinator 202rp verifies transaction coordinator 202n»'s signature on the response using 
transaction coordinator 202ip's certificate (sent with the response), and the root public key 
(which may be stored in hardware security module 218rp). Transaction coordinator 202rp 

25 then creates a signed OCSP request for the issuing participant's transaction coordinator 
certificate and sends it to root entity 110. 

In step 8064, transaction coordinator 202^ of root entity 110 stores the raw request in 
raw transaction log 212r. In step 8066, transaction coordinator 202r stores relevant billing 
data in billing log 208r. In step 8068, transaction coordinator 202r verifies the signature on 

30 the request. Transaction coordinator 202r then sends flie request to its OCSP responder 204r. 
OCSP responder 204r checks its local repository to determine the status of the subject 
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certificate and sends a response back to transaction coordinator 202^. Transaction 
coordinator 202r then sends a signed response to transaction coordinator 202rp. 

In step 8070, transaction coordinator 202rp of relying participant 104 stores the raw 
response data in raw transaction log 212rp for non-repudiation purposes. In step 8072, 
5 transaction coordinator 202rp checks with transaction coordinator 202r of root entity 1 10 to 
ensure that the issuing participant has sufficient collateral to issue the warranty. 

In step 8074, transaction coordinator 202r stores the raw request in raw transaction 
log 212r. In step 8076, transaction coordinator 202r stores relevant billing data in billing log 
208r. In step 8078, transaction coordinator 202r sends a yes or no response to transaction 
1 0 coordinator 202rp of relying participant 1 04 concerning whether issuing participant 1 02 has 
sufficient collateral to issue the warranty. 

In step 8080, transaction coordinator 202rp stores the raw response data in raw 
transaction log 212rp for non-repudiation purposes. In step 8082, transaction coordinator 
202rp creates a warranty rei^onse from the responses received from transaction coordinator 
1 5 202ip, signs it, and sends it to relying customer 1 08 along with transaction coordinator 
202rp's certificate. 

In step 8084, relying customer 108 verifies the response using the root public key 
stored in hardware security module 230. In step 8086, relying customer 108 sends a request 
to transaction coordinator 202rp for transaction coordinator 202rp's certificate to see if it has 

20 been revoked. 

In step 8088, transaction coordinator 202rp verifies the signature on the request and 
sends a request to its local OCSP responder 204rp to ensure that relying customer 108*s 
transaction coordinator certificate has not been revoked. In step 8090, local OCSP responder 
204rp sends a response to this request to transaction coordinator 202rp. In step 8092, 

25 transaction coordinator 202rp sends an OCSP request for its certificate to transaction 
coordinator 202r. 

In step 8094, transaction coordinator 202r verifies the signature on the request and 
checks with its local OCSP responder 204r to determine the status of transaction coordinator 
202rp 's certificate. Transaction coordinator 202r then forwards the response received from 
30 local OCSP responder 204r to transaction coordinator 202rp. 
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In step 8096, transaction coordinator 202rp forwards the response received from 
transaction coordinator 202r to relying custonaer 108. In step 8098, relying customer 108 
sends an acknowledgment to subscribing customer 106. 

In a preferred embodiment, each transaction coordinator 202 provides atomicity, 
5 consistency, isolation, and durability to transactions coordinated by the transaction 

coordinator. Atomicity means that all actions required to complete a transaction succeed or 
all fail; the transaction is an indivisible imit of work. Consistency means that after a 
transaction is executed, the system is left in a correct, stable state, or retums to the state 
preceding initiation of the transaction. Isolation means that each transaction is unaffected by 
10 other transactions that may execute concurrently. Durability means that the effects of each 
transaction are permanent after the transaction is committed. The combination of atomicity, 
consistency, isolation, and durability are sometimes referred to as ACID properties. 

Transaction coordinators 202 preferably provide ACID properties in a distributed 
computing environment by incorporating a transaction processing monitor or component 
15 transaction monitor. Suitable transaction processing monitors may include BEA TUXEDO 
from BEA Systems, Inc., MSMQ from Microsoft, Top End from NCR Corporation, and 
Encina from IBM Transarc. Suitable component transaction monitors may include Orbix 
OTM from lona Technologies Inc. and BEA WebLogic from BEA Systems, Inc. 

Any combination of steps to be coordinated by a transaction coordinator may be 
20 combined to form a transaction having the ACID properties- Preferably, one or more 

pre-defined transactions are provided for each of the process flows depicted in Figs. 5-7. 
Thus, for example, the steps occurring between the request and response depicted in Fig. 5 
may be combined to form a transaction having ACID properties. 

In a preferred embodiment, transaction coordinator components interact with the 
25 transaction processing monitor via a transaction processing library. To facilitate a flexible 
architecture whereby the implemented transaction processing monitor may be replaced with 
an alternate transaction processing monitor, libraries may be written to access transaction- 
processing-monitor functionality regardless of the particular brand of transaction processing 
monitor used. 

30 Each of the above-listed transaction processing monitors has certain features that 

relate to its suitability for incorporation in a transaction coordinator of the present system. 
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For example, TUXEDO transaction process monitors are designed to provide: (1) a 
high-performance message-passmg engine (2) distributed transaction management, allowing 
clients and servers to participate in a distributed transaction and to manage two-phase commit 
processes transparently to applications (3) an application to transaction manager interface 
allowing developers to write BEA TUXEDO applications regardless of the hardware hosting 
program (4) dynamic workload balancing that automatically generates and manages parallel 
copies of applications and ensures that they are evenly utilized (5) transaction queuing that 
allows distributed applications to work together in an asynchronous, connectionless fashion 
and that prioritizes queues based on message context, content, and time of day (6) data 
dependent routing that enables transactions to be processed where the data can be most 
efficiently utilized (7) automatic recovery from application failures, transaction failures, 
network failures, and node failures in which the server manager restarts the failed process 
and recovers the failed program by rolling back the transaction that was in progress. 

MSMQ transaction processing monitors from Microsoft are designed to provide: (1) 
full COM component support (2) access from a range of programming languages (e.g. Visual 
C++, Visual J++) (3) five APIs (open, close, receive, send, and locate) providing advanced 
message queuing benefits (4) sliding-window protocols, recoverable storage, dynamic 
routing to deliver messages, and on-time, in-order message delivery (5) the abiUty to be 
included within transactions that contain other activities, such as database updates (6) the 
ability to commit or abort operations with other resources to preserve data integrity during 
transactions (7) built-m message encryption, integrity, and signature support and (8) 
administrators the abUity to specify which MSMQ events should create an audit record in the 
Windows NT Security Log. 

MSMQ is typically included as a feature of both MS Windows NT Server, Standard 
Edition 4.0 and MS Wmdows NT Server, and Enterprise Edition 4.0. If support for more 
than twenty-five clients, cost-based routing, or the MSMQ Connector is needed, MSMQ is 
preferably run on >rr Server and Enterprise Edition 4.0. It should be noted that although 
MSMQ is a high-performance message-passing engine, it does not have necessary features of 
a transaction process monitor, and therefore may not be suitable for use in the present 
system. 
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IBM Encina is available from Transarc on many hardware platforms including Sun, 
IBM, Digital Equipment Corp., Hewlett Packard, and Windows. IBM Encina transaction 
processing monitors are designed to provide: (1) interoperability to allow the development of 
distributed transaction processing applications that integrate a wide variety of systems (2) 
5 concurrent use of multiple XA-compliant databases or resource managers, such as Oracle, 
Ingres, Informix, or Sybase through an X/Open XA application programming interface and 
provide mainframe LU6.2 interoperability, including sync-level 0, 1, and 2 services, without 
requiring additional software on the mainframe (3) performance and reliability required by 
transaction processing applications (4) an efficient, fully-distributed two-phase commit 

10 mechanism (5) automatic load balancing and replication of application servers to increase 

performance and to eliminate single points of failure (6) inherited security mechanisms of the 
underlying DCE thereby allowing both clients and servers to verify the identities and 
privileges of participants in a transaction (7) additional security mechanisms, including 
automated authorization checking and facilities to allow the constmction of audit trail records 

15 (8) enterprise-wide scalability in order to support large numbers of users and large amounts 
of data and (9) a centralized administration facility to permit effective management. 

Top End transaction processing monitors are designed to provide: (1) robust 
middleware (2) distributed transaction management (3) client/server interaction (4) reliable 
file transfer (5) dynamic workload bsdancing (6) recoverable transaction queuing (7) 

20 application parallelization (8) two-phase commit processing (9) automatic recovery (10) 

message-sensitive routing (1 1) multiple database support (Microsoft SQL Server, Oracle, and 
Sybase) and (12) Internet ajyplication scalability and availability. 

In a preferred embodiment, each transaction coordinator in tiie present system is 
adapted to provide a plurality of security services including: authentication, authorization, 

25 session security, message security, non-repudiation, and auditing. 

In a preferred embodiment, the transaction coordinator uses PKIX authentication 
based on a PKI defined by root entity 110. Other authentication mechanisms for services 
outside the present system may be supported as determined by the entity operating the 
transaction coordinator. 

30 In a preferred embodiment, authentication is provided through the use of digital 

signatures. Authentication may take place at the session level, the message level, or both. 
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In a preferred embodiment, transaction coordinators 202 provi 

V * 1 ver rsSL^ SSL typically provide three levels of session security, 
using a secure socket layer (SSL). SSLtypi y p communications to 

confidentiality.dataintegrity.andsessionauthentication. Preferably, all 

and from transaction coordinators 202 are encrypted usmg SSL. 

Lsage security intbe present system ispreferablyprovidedthrou^ 

.,itals"es. Digllsignaturesprovidetwolevelsofmessage.^^^^^^^ 

!:lLgrity. Digital signaturestypicallyptovideautben.^^^^^ 

* T^rivate kevs which are used for signing messages. 
, ■^^-".s^rr.l.di.tal.gna.urespreferah.ypro.dedata.tegri.^ 

ahashormessageaiges..ha.isgenera.edauring,hesigna»eprocess. Message drges. 
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provide a "fingerprint'* of the data such that if any bit of the signed data is modified, a 
different "fingerprint" will result and the recipient of the data will not be able to verify the 
signature. 

In a preferred embodiment, confidentiality is provided at the session level for all root 
5 communications. The transaction coordinator preferably complies with confidentiality rules 
specified by root entity 110. 

In a preferred embodiment, each transaction coordinator 202 records all data needed 
to ensure non-repudiation of a performed service in logs and ensures the integrity of those 
logs. For example, relying participant 104 preferably provides such non-repudiation for all 
10 services it performs for relying customer 108. Thus, for each service performed, transaction 
coordinator 202rp not only provides a response to relying customer 108 but also retains all 
data necessary to ensure that none of the parties involved in performing the service can 
repudiate having provided the service. 

In a preferred embodiment, digitally signed messages provide the basis for this 
15 non-repudiation. As noted, for example, in the context of the validation service described 
above, transaction coordinators 202 maintain a log of all received messages for 
non-repudiation purposes. Preferably, transaction coordinators 202 log messages exactly as 
received and do not parse, modify, or store messages in any format other than the format in 
which they were received. Modification of received messages renders the message's digital 
20 signature unverifiable and thus makes the message unsuitable for non-repudiation purposes. 

In a preferred embodiment, each received message is time stamped as part of the 
non-repudiation service. Responses are associated with authorization checks performed at a 
certain point in time. Preferably, the time of the authorization check is a signed attribute in 
the response and is captured in raw transaction log 212. 
25 In a preferred embodiment, transaction coordinator 202 also logs information for 

auditing purposes. Security audit logs may be used to detect potential attacks against the 
system, such^as a suspicious niunber of requests fi-om non-customers or a suspicious number 
of invalid signatures. Security audit logs may also assist when a key compromise occurs 
because a key may be compromised before it is reported and its associated certificate is 
30 revoked. The security audit logs may preferably be used to determine if transactions 
occurred using a compromised key. 
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An audit trail is maintained for purposes of dispute resolution, non-i«pudiation, and 
billings. In a preferred embodiment, a transaction coordinator logs every message that it 
sends or receives and logs the entire message. Messages may be logged in "raw" format. 
Alternatively, the transaction coordinator may break the message into its constituent parts 
and store it in a schema such that the entire message can be reconstructed in a manner that 
preserves the signature. In a preferred embodiment, logs are of such a nature that log entries 
cannot be falsified (added / deleted / altered) without being detected. In addition, if a 
transaction coordinator logs a message m raw format, it preferably includes the capabiUty to 
convert the raw data into a format readable by a COTS solution. This may be a loosely 
coupled utility or a part of the transaction coordinator functionality that runs as a separate 
and perhaps lower priority / background process. It may also run on an entirely separate 
system. TKe logs may contain other data related to the transport and the session. As an 
example this may mclude, sender / recipient IP address, the URL of the post, SMTP header 
etc. 



Transport services component 306 (shown in Fig. 3) preferably comprises a secure 
communications component that establishes a secure socket layer session between transaction 
coordinator 202 and the entity with which it is communicating. In a preferred embodiment, 
the secure communication component performs session authentication, as described above. 
Thus, when transaction coordmator 202 acts as a server 90, the secure communications 
component provides server-side session authentication and may request client-side session 
authentication. In contrast, when transaction coordinator 202 acts as a client 95, the secure 
communications component is responsible for authenticating server 90. 

As a client, transaction coordinator 202 is also preferably responsible for establisWng 
session security by generating a session key and sending the key, which is encrypted with the 
25 server's pubUc key, to the transaction coordinator server with which it wants to 

communicate. Subsequent communications between the two parties are enciypted with that 
session key. 

Fig. 12 is a composite block/flow diagram that depicts a preferred embodiment of the 
security-relevant flows associated with components of transaction coordinators 202. As 
shown in Fig. 12, in step 1202, a request is received by transport services component 306. In 
step 1204, transport services component 306 delivers the request to request manager 304. 
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Preferably, request manager 304 ensures that all security-related functions are performed on 

incoming messages before the messages are processed. 

In step 1206, request manager calls logging component 320 to log the raw request 

data. Logging component 320 gathers the data required to support non-repudiation and 
5 auditing. As noted above, all requests and responses are preferably logged as received. 

In step 1208, request manager 304 determines if a signature on the request is 

required. In step 1210, if request manager 304 determines that the request does not need to 

be signed, request manager 304 calls customer authorization check module 54 vnth the 

client's utility certificate. 
10 In step 1212, if request manager 304 determines that a signature is required, request 

manager 304 calls customer authentication module 408. In step 1214, customer 

authentication module 408 verifies the signature on the request and validates the certificate 

chain by calling signing component 324. 

Preferably, signing component 324 provides message security and supports the 
1 5 session and message authentication services. Signing component 324 interfaces with 

hardware security module 218, which performs all cryptographic Amotions. Root 110 

preferably specifies the digital signature method that will be used to sign all transactions. 

Signing component 324 preferably interfaces with hardware security module 218 to perform 

all cryptographic Amotions involved in the signature verification process. 
20 In step 1216, customer authentication module 408 checks the status of the customer's 

warranty certificate by sending a request to OCSP responder 204 via certificate status check 

comi>onent 414, as described above. 

In step 1218, customer authentication module 110 calls customer aufiiorization check 

module 418 with the customer's warranty certificate. In step 1220, customer authorization 
25 check module 41 8 checks customer database 214 to make sure the request came fi-om a 

customer authorized to obtain the requested service. In step 1222, a response regarding 

authorization is returned to request manager 304 and processing of system provided services 

continues as described above. 

Preferred security requirements for network communications between transaction 
30 coordinators and the following entities: customers, OCSP responders, and other transaction 

coordinators will now be described. These preferred requirements are described in the 
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context of an example in which relying customer 108 submits a request to relying participant 
104. 

When transaction coordinator 202rp of relying participant 104 receives a request from 
a relying customer 108, transaction coordinator 202rp authenticates the request. Signatures 
are typically required on all messages sent to transaction coordinator 202rp by relying 
customer 108. In addition, transaction coordinator 202rp may reqxiire relying customer 108 
to provide secure socket layer client-side session authentication. 

Preferably, transaction coordinator 202rp provides authentication of all messages it 
sends to relying customer 108. In addition, transaction coordinator 202rp provides secure 
socket layer server-side session authentication when any session is established with relying 
customer 108. 

In a preferred embodiment, transaction coordinator 202rp performs authorization 
checks to determine if relying customer 108 is an existing customer of relying participant 
104. Transaction coordinator 202rp may also perform authorization checks to determine if 
relying customer 108 is authorized to receive the type or level of service being requested. 
Preferably, relying customer 108 has an entry in customer database 214rp that lists the 
services to which it is entitled. Preferably, relying customer 108 is identified by a 
distinguished name as it exists in its warranty certificate and may also be identified by its 
distinguished name as it exists in its utility certificate if secure socket layer client-side session 
authentication is employed. This aspect of the transaction coordinator may be integrated 
with COTS access control / authorization packages. 

In a preferred embodiment, transmissions between relying customer 108 and 
transaction coordinator 202rp are encrypted in accordance with specifications specified by 
root entity 100 and server-side authentication is required. 

Typically, messages exchanged between relying customer 108 and transaction 
coordinator 202rp are digitally signed. Preferably, transaction coordinator 202rp verifies all 
signed messages received, validates the certificate chain, and ensures that the certificates 
within the chain have not been revoked. In addition, transaction coordinator 202rp signs all 
messages it sends to relying customer 108. 

In a preferred embodiment, transaction coordinator 202rp provides a non-repudiation 
service for relying customer 108. Transaction coordinator 202rp typically logs all responses 
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relating to requests for service received from any root component. This includes other 
components of transaction coordinator 202rp as well as components of other participants and 
root 1 10. Preferably, relying participant 104 logs all requests for services from relying 
customer 108 and all acknowledgments received from relying customer 108 indicating the 
5 receipt of a response in order to protect itself from repudiation claims from its customers. 

In a preferred embodiment, transaction coordinator 202rp logs all requests for 
services from relying customer 108 for auditing purposes. Accordingly, a system 
administrator can detect potential attacks against the system and determine if requests for 
services were received after a key compromise occurred. Auditing of requests may also be 

10 used to support any billing disputes that may arise. 

In a preferred embodiment, transaction coordinators 202ip, 202rp, and 202r 
conununicate respectively with OCSP responders 204ip, 204rp, and 204r only, i.e., OCSP 
responders that are within their financial institution. To request a response from an OCSP 
responder 204 at another financial institution, communications must preferably go through 

15 the other financial institution's transaction coordinator 202. 

Preferably, OCSP responders 204h>, 204rp, and 204r know the identity of the entity 
from which they are receiving a request and transaction coordinators 202ip, 202rp, and202R 
know the identity of the entity from which they are receiving an OCSP response. Preferably, 
co-located transaction coordinators 202n^ 202rp, and 202r and OCSP responders 204n», 204rp, 

20 and 204r know that they are receiving messages fix>m a local process without any e^qplicit 

authentication. In this case, neither secure socket layer authentication nor signed requests are 
required. However, OCSP responders 204ip, 204rp, and 204r may typically sign all responses 
and transaction coordinators 202ip, 202rp, and 202r may typically accept signed responses in 
accordance with the Internet PKI OCSP specification. 

25 If transaction coordinators 202ip, 202rp, and 202r and OCSP responders 204ip, 204rp, 

and 204r are not co-located and cannot ascertain imambiguously with whom they are ~ 
commimicating, authentication between the components is preferably required. 
Authentication of requests may be either at the session level or the message level. 
Authentication of responses is preferably at the message level and may be at the session 

30 level, as well. 
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It should be recognized that transaction coordinators 202ip, 202rp, and 202r do not 
typically perfonn authorization checks on OCSP responders 204ip, 204rp, and 204r since 
OCSP responders 204n>, 204rp, and 204r do not typically request services from transaction 
coordinators 202ip, 202rp, and 202r. 
5 Because OCSP responders 204 are preferably co-located with their respective 

transaction coordinators 202, transmission security mechanisms do not typically have to be 
provided for communications between them. Because the two components are contained 
within a physical environment that is completely under the control of one financial 
institution, protection can preferably be provided through policy as opposed to 
1 0 implementation of security mechanisms. 

However, if these components are not co-located, the transmissions are preferably 
protected against network attacks that could compromise the confidentiaUty or the integrity 
of the transmissions. Preferably, SSL is used to provide this protection. 

In a preferred embodiment, each OCSP responder 204 is co-located with its 
1 5 respective transaction coordinator 202 and transaction coordinator 202 therefore need not 
sign OCSP requests. However, OCSP responder 204 may sign responses if required by 
specifications specified by root entity 110. ^ 

In cases where OCSP responses are signed, they are preferably logged with the 
signature of the responder intact, in particular when the response is directly related to the 
20 service being provided. However, if transaction coordinator 202 has requested an OCSP 
response as part of an authentication check on a request for service, the OCSP response is 
typically not logged for non-repudiation purposes. This is because the OCSP check is 
performed to determine whether or not to process the incoming request, not as part of 
processing the request itself Only information relating to the processing of the request is 
25 necessary to retain for non-repudiation purposes. In a preferred embodiment, local OCSP 
responses are typically only logged when relying participant 104 is also issuing participant 
102 of the certificate in question and the OCSP request is part of the process for providing a 
service, e.g., checking the subscribing customer's certificate during a vaKdation request for 
that certificate. 

In a preferred embodiment, there are no requirements to log OCSP responses for 
security auditing purposes because OCSP responders 204 do not request services of 
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Secure sockets layers also support server and client authentication, negotiate 
encryption keys, and authenticate the server before data is exchanged by the higher-level 
application. Authentication is preferably provided through the use of digital signatures and 
public key certificates, which are exchanged at the time an electronic communication session 
5 is first established. 

In a preferred embodiment, each transaction coordinator is capable of accepting and 
sending messages over the public Internet using SMTP to send S/MIME messages and 
communicating via the HTTP protocol over an SSLv3 connection (HTTPS). In other words, 
each transaction coordinator is preferably adapted to support the following two modes of 
10 conmitmication: 

• HTTP over Secure Sockets Layer (SSLv3) - For synchronous communications (i.e. 
HTTPS). HTTPS is a hypertext transfer protocol that incorporates secure sockets layer 
between Web servers and Web browsers in order to transfer Web pages securely. Use of 
HTTP keep alive is reconmiended. 
15 • S/MIME v2 - For asynchronous communication using SMTP. 

In a preferred embodiment, each transaction coordinator acts as an HTTPS server 
during communications with the relying customer and as an HTTPS client when it makes a 
request to a transaction coordinator at another financial institution. In either mode, all SSL 
communication for credential status checking may employ only server authentication. 
20 In a preferred embodiment, each transaction coordinator may accept messages 

delivered via other transport protocols (e.g., HOP) approved by root entity 1 10. In addition, 
participants may implement other transport protocols locally by arrangement. In the absence 
of prior agreement, however, only HTTPS support should be assimied. 

In a preferred embodiment, Valicert's™ OCSP responder is used for certificate status 
25 check service 3 12. However, access to OCSP responder 204 may be achieved using libraries. 
Thus, by writing new libraries, new OCSP responder vendors may be implemented. 

Preferably, OCSP responder 204 determines certificate status without using a 
certificate revocation list. OCSP responder 204 may move most of the processing involved 
to a certificate authority, a component that issues, verifies, and revokes certificates, and 
30 eliminate the need to download potentially large certificate revocation lists. Altematively, 
these fimctionalities may be divided among different components which may be provided 
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with separate signing keys. For example, the function of issuing certificates may be 
separated from the revocation function, and components for performing these functions may 
be provided with separate signing keys. 

In a preferred embodiment, a hardware security module is used as a signing 
component. The hardware security module is preferably a liigh-speed device for signing and 
verifying signatures. The hardware security module is typically a networked hardware 
device that provides cryptographic services to authenticated entities. A suitable hardware 
security module is manufactured by NCipher. 

In a preferred embodiment, transaction coordinator 202 is always available to process 
requests during its normal operating times, which may be twenty-four hovirs a day seven days 
a week. To make sure the system meets availability requirements, a detailed requirement 
analysis of system-availability should be conducted. Because different participants may have 
different requirements, many different types of failures may occur. As is known, many 
different hardware and software vendors offer different options for high-availability systems. 
However, these options may or may not be available for the hardware and software that is 
chosen by a given financial institution. 

There are a number of known potential hardware failures that may affect a transaction 
coordinator. For example, the power supply to the server may fail. Preferably, a multiple 
redundant hot-swap power supply automatically swaps to a redundant power supply. If the 
server fails or crashes, the transaction coordinator preferably provides for high availability 
clustering for automatic fail over. In addition, the transaction coordinator preferably 
comprises a self re-start c^ability for automatically rebooting the server in the event of a 
network operating system (NOS) hang. 

The transaction coordinator also preferably comprises multiple redundant hot-swap 
disk drives and a disk array controller to handle disk feilure or crashes. The transaction 
coordinator also comprises a network interface to provide support for redundant network 
interface cards (NICs) in the event of NIC failure. In the event of cooling system failure, the 
transaction coordinator preferably uses redundant hot-swap cooling systems comprising hot 
swappable redundant fans which are individually removable. The transaction coordinator 
also preferably comprises an Intelligent Platform Management Interface to detect hardware 
and software failures. The Intelligent Platform Management Interface is an open 
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specification which simplifies and standardizes conununications for device management. In 
the event of memory corruption, the transaction preferably uses self-correcting memory. The 
self- correcting memory is preferably a managed error checking and correcting system 

memory and cache memory. 

In the event of application crashes, transaction coordinator 202 preferably uses 
transaction processing monitoring to restart the application. The transaction coordinator may 
also run redundant copies of an appUcation and the transaction process monitor may transfer 
transactions to the redundant copies. Certain appUcation availability features may require 
that the application to be coded in a spedfic way which may also help address application 
crashes. 

In the event of an operating system crash, transactions are preferably transferred to a 
standby machine that is supported by the network. Directory services, including middleware 
. Uke CORBA, may also be used to re-direct any new transaction requests to the new machine. 
In addition to the hardware and the software availabUity products, a monitoring 
infrastructure is preferably used to monitor the appUcations and the network. 

In a preferred embodiment, a software monitoring tool (such as Trivoli) is used to 
monitor applications, lliis tool is preferably configured to page the administrator in the 
event of application failure. A network monitormg system (such as that made by NetView) 
may also be used to allow administrators to monitor the network. 

Preferably, custom written appUcation daemons are used to simulate transactions. If 
these transactions fail, system administrators may be infomied. Also, database vendor tools 
may be used for database monitoring. Most databases provide database-monitoring tools that 
detect deadlocks and other databases problems. 

A distribution ^proach for the transaction coordinator may preferably be defined that 
is a fimction of what root entity 110 wishes to distidbute to participants. Application 
distributionmay typically be performed via Web-download from root entity 110. The 

Web-download mechanism may provide for selective download, authentication, and tracking. 

In a preferred embodiment, tiie transaction coordinator may be adapted to support 
integration with existing operational systems such as CICS, IMS and other legacy systems. 

Participants may choose to use the entire transaction coordinator architecture and 
fimctionaUty described above, or may instead choose to use components of the transaction 
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coordinator and add their own implementations to those components. The Web-download 
approach is preferably configured to fulfill the varying requirements of participants. The 
download mechanism preferably provides at least three download options: (1) a download 
transaction coordinator executable option (2) a source code or binaries of the transaction 
5 coordinator option and (3) a soxirce code of transaction coordinator classes option. 

The first option preferably accommodates participants that choose to use the 
transaction coordinator in its entirety. This option provides options for different platforms. 
The second option preferably accommodates participants that choose to plug components of 
the transaction coordinator described above into their own implementations. This download 

1 0 mechanism also provides options for different platforms. The third option preferably 

accommodates financial institutions that opt for heavy-duty development and choose only to 
use certain pieces of implementation of the transaction coordinator described above. 

Preferably, the download mechanism allows financial institutions to not only 
download the executable, but also the source code. Because the downloaded executable may 

15 be used on its own and the source code may be used to develop other custom applications, 

root entity 110 preferably provides download access only to those institutions that are trusted 
partners with root entity 110 and hence are authorized to use the transaction coordinator. 
Preferably, this is achieved via an authentication/authorization process. 

Root entity 110 may preferably track which participants download particular 

20 components of the transaction coordinator. This way root entity 110 may determine the 

versions of the transaction coordinator and/or its components that are being used at any given 
time. Root entity 110 may use this information to (1) charge a fee from the financial 
institutions for the downloaded component(s) and to (2) track versions of the transaction 
coordinator for maintenance purposes. 

25 Preferably, the transaction coordinator is adapted to be scalable to accommodate a 

growing user base without significant performance degradation. One step in fulfilling the 
scalability requirements for an application is to forecast the potential growth in the user base. 
In general, an application with a distributed architecture facilitates higher scalability by 
allowing distributed multiple instances of heavily loaded components to be running at a 

30 given time. The transaction coordinator architecture is preferably a distributed one and, 

therefore, supports scalability. In addition, the load--capacity of the transaction coordinator is 
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preferably base-lined on a chosen development machine. This information is used to select 
appropriate hardware to support the anticipated number of transactions. Preferably, the 
transaction coordinator (and OCSP responder) are adapted to reliably handle up to 1000 
validation transactions per minute. 
5 As noted above, OCSP checks are typically not performed on utility certificates. If 

signatures are not required on requests, there is no mechanism in place to ensure that the 
secure socket layer client-side certificates have not been revoked. Preferably, if a secure 
socket layer certificate has been revoked, financial institutions are informed out of band (e.g., 
a broadcast message) and the affected users are removed firom the participant's customer 
10 database. 

Each transaction coordinator typically tmsts some set of certificates that are stored on 
its hardware security module. No OCSP checks are performed on these certificates. If a 
revoked certificate exists on a hardware security module, it will not be detected during 
on-line processing. Preferably, financial institutions are notified if a certificate stored on a 

1 5 hardware security module has been revoked so that they can remove the certificate from the 
hardware security module. 

Transaction coordinators, when acting as clients, authenticate servers with whom they 
are communicating. But fliis check typically only guarantees that the server has a certificate 
that was issued by a certificate authority that the transaction coordinator trusts. There are no 

20 checks regarding the identity or status of the server itself. In a preferred embodiment, the 
transaction coordinator checks servers against a list of trusted servers and performs OCSP 
checks of the server* s certificate. However, since there is little to be gained by a server 
intercepting requests, the degradation of performance resulting firom these additional checks 
is typically not warranted. 

25 Typically, the transaction coordinator does not have automated processes for 

detecting potential attacks. Preferably, system and security administrators inspect audit logs 
periodically in order to identify such potential attacks. 

Typically, requests that do not pass a secure socket layer client-side autiientication 
check are not logged. If an attack (e.g., a denial of service attack) occurs at this level, there 

30 are no logs to reference. 
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In . prefmed emtodimort, the transacUon coordinator is protected by a fcewaU. 
Preferably, the firewaU conflponent naintains logs of incoming requests. 

The trar^action coordinator is preferably provided vith autonaated introsion detectron 
n^echanisms. "nrese processes typically watch incoming traffic or scan audit logs looking for 
suspicious activity, and take appropriate actions if necessary. 

The transaction coordinator preferably maintains logs for non-repudiation purposes. 
Often, hov^er. the system v«U not include functions to assistauserirr retrieving the data 

to support non.rei»>diadon. The user manuaUy searches through the logs to find 
M the supporting dat. In oflrer embodiments, automated non-repudiadon tools may be used 

to assist the user in this process. 

In a pref^red embodiment, transaction coordinators and OCSP responders employ 
normal Internet time out values for certificate stanza check requests. For other services, the 
time out value may be set as appropriate for the service. In a preferred embodiment, timeout 
values are configurable in the transaction coordinator. 

The following discussion outlines a possible hardware and software implementauon 

for a transaction coordinator. 

The main serv« used for d« transaction coordinator may be a Hewlett Packard 
Netserver m4. Preferably, the server has the foUowing specifications: 4 P2.450 MHZ 
processors. 51 2.768MB RAM. 40 - 60 GB HD with Raid 5 Array. UPS. and an external DLT 
40E DLT 4000 tape drive for tape backup. Pref«ably. at least five woricstations are used 
each having the foUowing specificaUons: P2400MHZ processors. 128 MB RAM, and 6GB 
HD. 

The transaction coordinator is preferably platfomi independent so that tt can be 
supported on servers based onMicmsofl WindowsNT 4.0/2000. Sun Solaris, and Hewlett 
Packard HP-UX. Implementation is preferably done in JAVA however some coding may be 

done in C/C++ as well. 

A Windows NT Server w/Service Pack 3 may be used as the operating system. 
Microsoft Visual SourceSafe 6.0 may be used for source control. Visual Ca« Professional 
Edition 3.0 ftom Symantec (Java Version 1 .2) may be used for development. SSL/J SDK 
ftom RSA Security Systems may be used for secure socket layer implementation and is also 
required by XETI's JKK. 
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For signature verification, nCipher's hardware security module may be used. For 
signatures from subscribing customers, Datakey smart cards may be used. Preferably, OCSP 
responders are provided with a toolkit that provides an interface to cryptographic functions 
and for ASN.l Communication. In a preferred embodiment, XETI's JKIX may be used for 
5 this purpose. 

For digital time stamping. Datum's TYMSYNC or other trusted time source may be 
used. An MS SQL Server may be used for the databases described above. Code Warrier 
from Metro Works may be used for the development of portable C/C++ development. 
Codelntegrity may be used to perform code integrity checks to verify code portability. 

10 Typically, the size of the data that is passed between different entities is instrumental 

in the performance of a public key infrastructure system. Messages submitted between 
entities are therefore preferably analyzed to estimate the size of the data that is transmitted. 
The analysis may be done on the basis of tibie certificate fields defined in RFC2459 along 
with specific root extensions. 

1 5 The exact data lengths of the certificate fields, which have a fixed length, are 

preferably taken into account during the estimation. However, there are many fields for 
which the length varies. For these fields, a liberal estimate on the size is preferably made 
(i.e., larger rather than smaller). Also, estimates of overall message size preferably include 
the sizes for all extensions, i,e., if a message allows five different extensions, the size is 

20 preferably calculated on an assumption that all five extensions are being sent v^th the 
request. 

Fig. 13 depicts the different message (estimated) sizes passed between system entities 
in a preferred embodiment As shown in Fig. 13, the total estimated message size of 
messages passed from subscribing customer 106 to relying customer 108 is 2610 bytes. The 

25 message typically comprises two certificates, each 1 146 bytes, the issuing participant's 

certificate signed by root entity 110, 128 bytes, the issuing participant's signature, 128 bytes, 
and an HTTP header, 62 bytes. 

The total estimated message size of messages passed from relying customer 108 to 
relying participant 104 is 2022 bytes. The message typically comprises two requests, one 

30 concerning the subscribing customer's certificate and one concerning the issuing participant's 
certificate, each 55 bytes, a message extension, 210 bytes, a version number, 4 bytes, the 
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relying participanfs oame, 132 bytes, Ae relying participant's dgnature. 128 bytes, the 
relying customer's certificate, 1146 bytes, and an HTTP header, 62 bytes. 

The total estimated message si« of messages passed fixm, relying participant 104 to 
issuing participant 102 is 1601 bytes. The message typically comprises a request concemmg 
the subscribing customer's certificate or the issuing participant's certificate, 55 bytes, a 
message extension, 210 bytes, the root entity's signature on the relying participant's 
«msaction coordinator certificate, 128 bytes, the relying participant's transaction coordmator 
certificate, 1 146 bytes, and an HTTP header, 62 bytes. 

The total estimated message size of messages passed firom issuing participant 102 to 
relying participant 104 is 2086 bytes. The message typicaUy comprises a response 
concerning either tiie subscribing customer's certificate or the issuing particpant's 
certificate, 456 bytes, a message extension, 294 bytes, the issuing participant's certificate, 
1 146 bytes, the root entity's signature. 128 bytes, and an HTTP h«»ler. 62 bytes. 

Teetotal estimated message rize of mess^es passed firom relying participant 104 to 
relying customer 108 is 2213 bytes. Tlte message typically comprises a response concentmg 
the subscribing customer's certificate or the issuing participant's certificate. 55 bytes, a 
message extension. 210 bytes, the espouse fi^om tite relying participanfs ti^action 
coordinator. 127 bytes, the relying partidpant's transaction coordinator certificate. 1146 
bytes, the root entity's signature on the relying participant transaction coordinator's 
certificate, 128 bytes, and an HTTP header 62 bytes. 

The detail on message size estimation of different fields is depicted in the table 
below. Typically. fl« size of message being passed between tite entities is between 2K and 
3K. Once the transaction volume has been projected, this information is preferably used to 
estimate the network load. 



Certificate Size - No Extensions or Root Specific i nstructions 

Size Calculation Comments 



Certiiicate { 



TbsCertificate { 

Version 

Serial Number 
Integer 



Integer 



Size (in 
Bytes) 

4 
4 



-45- 



wo 01/020513 



PCT/USOO/24662 





Certificate { 


Size (in 
Bytes) 


Size Calculation Comments 




signature { 








Algorithm 


Object Identifier 


11 






Parameters 


Defined by 

Algorithm 


32 


Signature algorithm parameters are usually NULL but since 

parameters are allowed, 32 bytes have been assigned for it 


5 


} 








issuer 


Name 


132 


This is a higher estimate — approximated for 4 names. Name 
is defined as sequence of Relative Distinguished Name 




validity { 








notBefbre { 








utcTime 


UTCTime 


32 




10 


generalTime 


GeneralizedTime 


32 






} 








notAfler { 








UtcTime UTCTime 


32 






generalTime 


General izedTime 


32 




15 


} 








) 








subject 


Name 


132 


Viis is a higher estimate - approximated for 4 names. Name 
is defitted sequence of Relative Distinguished Names 




subjectPublicKeylnfo 


{ 








algorithm { 






20 


Algorithm 


Object Identifier 


11 






Parameters Defined by 
algorithm 


32 


Signature algorithm parameters are usually NULL but since 
parameters are allowed, 32 bytes have been assigned for it 




} 








subjectPublicKey BIT STRING 


12S 




25 


) 








tssuerUniquelD 


BIT STRING 


132 


Tliis is higher estimate. Usually if Issuer is defined, 
issuerUniquelD should not be used 




subjectUniquelD 


BIT STRING 


132 


Tliis is higher estimate. Usually if Subject is defined, 
subjectUniquelD should not be used 




extensions { 








extnlD 


Object Identifier 


0 


Certificate is being estimated without any extensions. ext^tlD 
would take J J bytes. 


30 


critical 


BOOLEAN 


0 


BOOLEAN would take 4 bytes . 




extnValue 


OCTET STRING 


0 


Will depend upon the extension 
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5 



Certificate { 


Size (in 
Bytes) 


Size Calculation Comments 


} 






} 






signatureAlgorithm { 






algorithm Object Identifier 


U 




parameters Defined by 

Algorithm 


32 




} 






Signature Value BIT STRING 


128 


This may vary from signer to Siguier. When signed by rooi, 
the size will be 256 when signed by the root 


} 






Total 


985 





Certificate Extension - with Root Instructions and Extensions 



15 



20 



25 



fCertifxcate Extensions/root entity Specific Instructions 


Size (in 
Bytes) 


Size Caletilation Comments /j^ . 


Must not contain Issuer Unique ID 


-132 




Must not contain Subject Unique ID 


-132 




Contain a Subject DN 


0 


Already present in certificate 


Extension subjectAItNames is supported as e-mail 


47 


Consists fa number of GeneralNames - root entity will 
support only rfc822 - email address - estimated at 32 bytes 
+ JJ bytes for extnlD and 4 bytes for critical flag 


Extension KeyUsage should appear in all Certificates 


17 


2 bytes for the bit string + 15 for extension parameters 


Extended Key usage should appear when appropriate 


65 


Consists of OID. Estimated at 5 OID « 55 Bytes + 15 for 
extension parameters 


Certificate Policies should be present with OID 


26 


1 } bytes for root entity OID + 1 5 for extension parameters 


Basic Constraints should be present 


19 


4 bytes for the Boolean + 0 bytes for /lie path since path is 
not being used + 15 bytes for extension parameters 


Subject Key ID should be prescni 


35 


20 bytes based on WO-hit SHA-I hash •¥ 15 bytes for 

extension parameters 


Authority Key ID should be present 


103 


20 bytes for the hash + 64 for the General Name - 
assumption that it could be URI -h- 52 + 4 for serial + 15 for 
extension parameters 


Must not contain Name Constraint 


0 


0 


Must not contain Policy Constraint 


0 


0 



-47- 



3NSDOCID: <WO_0120513A1.1A> 



wo 01/020513 



PCT/USOO/24662 



Certificate Extensions/root entity Specific lostnictions 


Size (in 
Bytes) 


Size Calculation Comments 


AIA must be used for OCSP and RM 


90 


64 bytes for general name + JI bytes for OID + J 5 for 
extension parameters 


Extension * Subscriber Information 


55 


20 bytes for warranty accotmt + 20 bytes for 
device id + 75 bytes for extemion parameters 


Total * 


193 




OCSP Request - with Root Instructions & Extensions 


6cSPRequest{ J ^^- - : • ' 'iv,. -i: 

i- ■■■ '''M I 


Size On 
Bytes) 


Size CalculaUon Commehts r 


TbsRequest { 






Version Integer 


4 




RequestorName Name 


132 




Request { 




77ifi Request structure repeats for each request in a 
particular OCSP request 


ReqCert { 






CertID{ 






HastAlgorithm { 






Algorithm OID 


n 




Parameters Defined by 
Algorithm 


0 


Estimated as O since no parameters passed on the 
implemeniation. 


} 






) 






IssuerNameHash 


20 




IssuerKeyHash 


20 




SerialNumber 


4 




} } ) } 






Total (Without Extensions) 


191 




RequestExtensions { 






Nonce ( 






OID 


11 




Nonce Value 


24 


No requirements have been imposed on Nonce Value. 
Estimated at 24 bytes 


) 
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OCSPRequest { 


Size (in 
Bytes) 


Size Calculation Comments 


ServiceLocator ( 






IssucrName 


132 




AIA 


32 




OlD 


11 




} } 






Total (With Extensions) 


401 





OCSP Response - with Root Instructions & Extensions 



10 


OCSPResponse ( 


Size (in 
Bytes) 


SizejCaiculation Comments ' 




RcsponseStatus { 








ResponseBytes { 








ResponseType 


DID 


11 






Response 


32 




15 


} 








BasicOCSPResponse { 








TbsResponseData { 








Version 


Integer 


4 






ResponderlD 


Name 


132 




20 


ProucedAT 


GenerallzedTime 


32 






) 








Responses { 




Repeated for each response 




CeitID{ 








Algorithm { 






25 


algorithm 


DID 


22 






parameters 


Defined by Algorithm 


0 






} 








IssuerNameHash 


20 






issuerKeyHash 


20 




30 


serialNumber 


4 






) 








CertStatus 


8 






JhisUpdate • 


32 
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OCSPResponse { 


Civ^ (in 

Bytes) 




NcxtUpdate 


0 


Not to be used in root entity Responses 


} 






SignatuFeAlgorithm { 






Algorithm { 






algorithm 


11 




Paxameteis 


0 




} 






} 


0 




SignatureValue 


128 




} 






Total (Without Extensions) 


4S6 




ResponseExtensions { 






Nonce { 






OID 


11 




Nonce Value 


24 




> 






CRLEntryExtension { 






Reason 


OID 


11 




Reasoned 


Enum 


4 




HoldlnstnictionCd 


OID 


11 




Holdlnstruction 


OID 


11 




InvalidityDate 


GeneializedTime 


32 




Ceitificatelssuer 


OID 


11 




CertificatelssuerName 


Name 


132 




) 






CRLReason { 






Reason 


OID 


11 




Reasoned 


Enum 


4 




Time 


GeneralizedTime 


32 




) 






Total (With Extensions) 


750 





Valid request and response times for OCSP transactions and warranty transactions 
and confirmation times for all transactions are preferably specified by root entity 110, The 
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following section describes preferred performance targets for the transaction coordinator. 
The response times noted refer qjecifically to the system response time. Preferably, lapsed 
timeframes in which manual processes are completed (noting the need for verification and 
requesting it, filing claims, etc.) are also established. 
5 Preferably, the validation request and response time (i.e., OCSP) is ten seconds or 

less for all response time transactions within the root control inj&astructure. Validation 
outside the root infi:astructure (from customer to customer or customer to root) preferably 
does not exceed sixty seconds. The total round-trip time preferably does not exceed seventy 
seconds. Preferably the response time includes latency on the Internet. The end-to-end 
10 response time preferably includes the longest validation path (i.e. subscribing customer to 
relying cmtomer to relying participant to issuing participant to root entity). 

An illustrative performance requirement may be as follows: No more than 6 seconds 
between the post of a certificate status check to a relying participant's transaction coordinator 
and receipt of a response and no more than 3 seconds to turn around a response to a 
15 certificate status check where the data for the response is locally available in a case where 
caching is in effect, proof of freshness (i.e., including status of participant certificates m 
messages transmitted by the participant) is in effect, a certificate chain of two certificates is 
bemg validated, the transaction is a four-comer transaction, and the system entities are 
connected to a 10 Mbps LAN (rather than the Internet). 
20 The warranty request response time includes offline transactions. Preferably, these 

offline transactions do not exceed an eight hour window starting at the end of a business day. 

The response time for response to notification of lost, compromised, or invalid 
certificates preferably includes offline transactions. Preferably, these offline transaction do 
not exceed one hour. 

25 The revocation of certificates also preferably includes offline transactions. 

Preferably, these offline transactions do not exceed one hour. 

The transaction coordinator also preferably provides confirmation of transactions. 
Online transaction requests preferably receive status confirmation, including incomplete 
request or response, within seventy seconds. The transaction coordinator also preferably 
30 provides a method of storing for retrieval mcomplete transaction requests or responses, a 
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It may D p ..^.g certificates sent with each m ^ as it appears in bis 

Urinating some or aU of the certm ^is distinguished name as it PP 
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monitors the rav^transactio 
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Co-locating the transaction coordinator and OCSP responder eliminates the need to 
sign and verify requests and to establish secvire socket layer connections between these 
components. 

Using secure socket layer between financial institutions and during commxmications 
5 with root entity 1 10 typically eliminates the need to digitally sign each request message. 

However, digitally signed requests provide a higher degree of security. Each participant may 
preferably assess the risks involved with trading off security for performance. 

Caching OCSP responses typically improves the turnaround time by reducing the 
time it takes to send and receive an OCSP request to the root entity. In a preferred 
10 embodiment, verification of OCSP responses is performed as the data is put into the cache as 
opposed to performing verification as part of the on-line transaction processing. 

In a preferred embodiment, a transaction coordinator may cache validity responses 
and use the cached responses to validate credentials. The period for which a response may be 
cached is preferably set as a policy matter by root entity 110. This period may preferably be 
1 5 within the 4 to 5 minute range. 

If a transaction coordinator implements the ability to used cached responses it is 
preferably adapted to log their use for billing and audit as well as non-repudiation purposes. 
The logged information preferably indicates that a cached response was used to validate a 
credential rather than a fi-eshly acquired response. 
20 For high value transactions, a client apphcation may prefer the use of a fi^esh response 

rather than a cached response. Accordingly, in a preferred embodiment, transaction 
coordinators preferably get and use a fireshly acquired validity response on explicit request to 
use a firesh response rather than a cached response. 

In a preferred embodiment, the recipient of a response checks the status of the 
25 responder's certificate. Altematively, to eliminate this second request, the transaction 
coordinator may automatically include the status of its certificate (as signed by the root) 
whenever it sends a response to either a relying customer or to another transaction 
coordinator. 

The following section discusses testing of the transaction coordinator. Preferably, the 
30 transaction coordinator is tested for the items listed in this section. 
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In order to provide architectural flexibility, the transaction coordinator is preferably 
ported to more than one hardware platform (e.g. Microsoft Windows NT 4.0/2000, Sun 
Solaris and Hewlett Packard HP-UX). This allows participants to choose their own hardware 
platform from the list of the supported platfonns. Tests are preferably performed to ensure 
that the transaction coordinator is installed smoothly on each of the supported platforms. To 
enable such testing appropriate hardware is typically required. 

Tests are preferably performed to ensure that the transaction coordinator may be 
installed and uninstalled on a clean Windows NT Machine. 

If the transaction coordinator is extended to support other operating systems, tests are 
preferably performed to ensure that the executable derived from the same souree code can be 
installed on all of the supported operatmg systems. Appropriate hardware with appropriate 
operating systems may be required to perform these tests. 

Preferably, the transaction coordinator interfaces with otiier tiiird party vendors- 
software tools. The interfeces to these software tools are preferably tested on the 
development site during development and system test phase. In addition, elaborate testing is 
typically done at the customer site to ensure that tiie transaction coordinator interface witii 
these tools is stable. This may be done during customer/functionaUty testing, described 

below. 

The fimctionality of the transaction coordinator is preferably tested during 
development and system test phases. During tiiese tests, appropriate tools are used to ensure 
that all of the custom written code is exercised at least once. In a anotiier preferred testing 
phase, customers test the fimctionality of the transaction coordinator. 

Security is a critical piece of the transaction coordinator. Preferably, testing is done 
to ensure tiiat data is transferred securely from one point to another. Test cases are 
preferably created to exhaustively test the security aspect of the pubUc key infrastructure. 

A messaging protocol definition for messages transmitted withm system 200 and a 
certificate status protocol defuiition for system 200 are described in copending United States 

provisional patent application serial No. , filed on even date herewitii. 

entitied Transaction Coordinator Certificate Status Check (CSC) Protocol Defmition. 
Transaction Coordinator Messaging Protocol Definition, and Transaction Coordinator 
Requirements, which is hereby incorporated by reference. In a preferred embodiment, each 
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transaction coordinator supports this messaging protocol definition. Specifically, each 
transaction coordinator accepts and routes all valid XML messages as defined in the 
messaging protocol definition, logs and reports ill-formed messages, and is able to generate 
valid XML messages in response to requests. 
5 In an altemative embodiment, the system may instead be implemented as an OCSP 

centric model that does not employ transaction coordinators 202. This altemative 
embodiment employs enhanced OCSP responders adapted to provide significantly more 
functionality than normally provided by a typical OCSP responder. In particular, the 
enhanced OCSP responder is adapted to provide the following additional functionality: 
10 • Encrypted communication using SSL. 

• Logging of raw transactions for both requests and responses. 

• Providing of certificate chains with responses. 

• Verification of signatures on requests preferably using an HSM. 

• Validation of certificate chains accompanying requests (parts of which may be 
1 5 stored in a local database or on an HSM). 

• Creation of new requests based on: 

• A value in a service locator request extension of a received request 

• An authority information-access extension in the certificate accompanying a 
response. 

20 • Suspension of processing on a request until responses are received on these 

other newly created requests, i.e., ability to synchronize responses to requests. 

• Forwarding of responses, when appropriate. 

This altemative embodiment provides only portions of the certificate status check 
service without providing the flexibility of adding new services. Also, billing is not 
25 implemented in this altemative embodiment. In addition, this altemative embodiment may 
cause vendor locking. A detailed list of the pros and cons of this altemative embodiment is 
provided below. 

Fig. 14 depicts the transaction flows for this altemative embodiment. The message 
flows in Fig. 14 are summarized in the following table: 



30 



The Subscribing Customer (SC) sends signed data, the signature, the SC and the IP 
certificates (and optionally CSSD) to the Relying Customer (RC). 
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2 


The RC verifies the signature on the data sent by the SC and validates the SC's 
certificate chain and then creates an OCSP request containing the SC certificate serial 
number. This data is sent to the HSM for signature. 


3 


The OCSP request for the SC's certificate, signed by the RC is sent to the Relying 
Participant (RP) OCSP Responder (OR) along with the RC's certificate chain. The 
entire certificate chain must be passed with the message. 


4 


The RP OCSP Responder logs the request in its OCSP log. The RP OCSP 
Responder verifies the signature on the request and validates the RC's certificate 
chain. All verification if performed is software. The entire chain (including the 
root) must be passed with the message in order for verification of the 
signature/certificate chain to be performed. No checks are performed to ensure that 
the RC's certificate has not been revoked. 


5 


The RP OCSP Responder creates a new request, containing the single request 
received fi-om the RC, and signs it using its HSM. Signed requests between financial 
institutions are not required. Instead, the root entity (ROOT) may require SSL 
client-side authentication in which case the verification/validation/customer look up 
is based on the certificates associated with the SSL connection. 


6 


The RP OCSP Responder sends the signed OCSP request to the appropriate Issuing 
Participant's OCSP Responder based on the value in the Service Locator request 
extension of the received request. 


7 


The IP OCSP Responder logs the request in its OCSP log. The IP OCSP Responder 
verifies the signature on the request and validates the RP OR's certificate chain. All 
verification if performed in software. The entire chain (including the root) must be 
passed with the message in order for verification of the signature/certificate chain to 
be performed. 


8 


The IP OCSP Responder creates an OCSP request containing the serial number of 
the RP OCSP Responder' s certificate and signs it using its HSM. 


9 


The IP OCSP Responder then sends the request to the ROOT OCSP Responder based 
on the authority information access extension in the certificate associated with the 
signature on the request received in Step 4. The IP OCSP Responder waits for a 
response firom the ROOT regarding the RP OCSP Responder' s certificate before 
issuing a response on the SC's certificate. If the IP only requires SSL client-side 
authentication and does not require signed OCSP requests, this step may not be 
necessary. 


10 


The ROOT OCSP Responder logs the request in its OCSP log. The ROOT OCSP 
Responder verifies the signature on the request and validates the IP OCSP 
Responder' s certificate chain. Signed requests between financial institutions are not 
required. Instead, the ROOT may require SSL client-side authentication in which 
case the verification/validation/customer look up is based on the certificates 
associated with the SSL connection. 
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11 


The ROOT OCSP Responder checks its local database to determine the status of the 
RP OCSP Responder' s certificate, then it generates a response and signs it using its 
HSM. 


12 


The ROOT OCSP Responder then retxims the response to the IP OCSP Responder. 


13 


The IP OCSP Responder logs the response in its OCSP log. The IP OCSP Responder 
verifies the signature on the request and validates the Root's OCSP Responder 
certificate chain. It should be noted, however, that there may not be enough 

UULiJXXIlctllOIx lllCtlllUllIiCU 111 UlC i(Jgk> IXJ oULipUXL lI(JXl^XC^UiJ.lClUdi.i. XXXC C/XXIXXC? wCX LXXIWCILC 

chain must be passed with the message. 


14 


The IP OCSP Responder then checks its local database to deteraiine the status of the 
SC's certificate. The IP OCSP Responder generates a response and signs it using its 
HSM, 


1 s: 


TlitfA TP Or^QP Pf^cnnnrl^r c«»nHc fVi^ cifmp^H r^cnoncf^ tn tVi^ PP Of^^P P^QnnnHf^ 
xiic ix xjK^iDjr xvCdpunciCx bciiuo iixc digncu rcopuxidC ikj ixxc xvr v/v^ox xvcopwixucx. 


16 


The RP OCSP Responder logs the OCSP response in the OCSP log. The RP OCSP 

jvcbpuncicr vcxxiJ.co iixc oxgiiaiurc un uic rcopviiibc oiiu. voixuaLCd uxc xxr 2> wv^ojt 
Responder certificate chain. The entire certificate chain must be passed with the 
message. 


1 7 


i ixc xvJT Kjy^iDx xvcbponacr cxcaics an kj\-^idx xcc^ucsl cunLa.iixiiig Lxxc 5crxcii numucr oi 
the IP OCSP Responder' s certificate and signs it using its HSM. 


18 


The RP OCSP Responder then sends the request to the ROOT OCSP Responder 
based on the authority information access extension in the certificate associated with 
inc bigiia-iurc uix iixc rcspuiibc received iii ^tcp i*t. 


19 


The ROOT OCSP Responder logs the raw request in its OCSP log. The ROOT 
OCSP Responder verifies the signature on the request and validates the entire RP 
KJK^ijr ixcspunucr s ccrLxxiuaic cnaxu. i nc cxxiirc vcrLiixcciic cxxaxxx xixuoi oc pa5s>cu wxixi 
the message. 


20 


The ROOT OCSP Responder checks its local database to determine the status of the 
IP OCSP Responder' s certificate, then it generates a response and signs it using its 
HSM. 


21 


The ROOT OCSP Responder sends the signed response to the OCSP Responder. 


22 


The RP OCSP Responder logs the response in its OCSP log. The RP OCSP 
Responder verifies the signature on the response and validates the Root's OCSP 
Responder certificate chain. The certificate chain may be passed with the message, 

or narts of the chaiTi mav tp^jiHp ^*ithpr on thp T-IS^^ or in the Certificate Verification 

database. 


23 


The RP OCSP Responder creates a response for the RC that contains information it 
received in step 2 (e.g., the nonce) and the status information on the SC's certificate 
it received in step 14 and signs it using its HSM. 
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24 


The RP OCSP Responder returns the response to the RC. 


25 


The RC uses its HSM to verify the signature on the response and validate the RP's 
OCSP Responder certificate chain- The certificate chain may be passed vsdth the 
message, or parts of the chain may reside on the HSM. 


26 


The RC creates an OCSP request containing the IP's certificate serial number. This 
data is sent to the HSM for signature. 


27 


The OCSP request for the IP's certificate, signed by the RC, is sent to the Relying 
Participant (RP) OCSP Responder (OR) along with the RC's certificate chain. The 
entire certificate chain needs to be passed with the message. 


28 


The RP OCSP Responder logs the request in its OCSP log. The RP OCSP 
Responder vermes the signature on the request and validates the RC s certificate 
chain. All verification if performed in software. The entire chain (including the 
root) must be passed with the message in order for verification of the 
signature/certificate chain to be performed. No checks are performed to ensure that 
the RC's certificate has not been revoked. 


29 


The RP OCSP Responder creates a new request, contammg the single request 
received firom the RC, and signs it using its HSM. Signed requests between financial 
institutions are not required. Instead, the ROOT may require SSL client-side 
authentication in which case the verification/validation/customer look up is based on 
the certificates associated with the SSL connection. 


30 


The RP OCSP Responder sends the signed OCSP request to the ROOT OCSP 
Responder based on the value in the Service Locator request extension of the 
received request. 


31 


The ROOT OCSP Responder logs the request in its OCSP log. The ROOT OCSP 
Responder verifies the signature on the request and validates the RP OR's certificate 
chain. All verification is performed in software. The entire chain (including the 
root) must be passed with the message in order for verification of the 
signature/certificate chain to be performed. 


32 


The ROOT OCSP Responder checks its local database to determine the status of the 
RP OCSP Responder's certificate, then it generates a response and signs it using its 
HSM. 


33 


The ROOT OCSP Responder then returns the response to the RP OCSP Responder. 




me Kr ucor Kesponaer logs the response in its OCSP log. The RP OCSP 
Responder verifies the signature on the response and validates the ROOT'S OCSP 
Responder certificate chain. It should be noted that there may not be enough 
Information maintained in the logs to support non-repudiation. The entire certificate 
chain must be passed with the message. 
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This OCSP proxy centric model has advantages and disadvantages when compared to 
the transaction coordinator model described above. The pros and cons of this.altemative 
embodiment are summarized in flie table below: 



15 



Pros 


Cons 


Takes away some of the complexity of 
implementing the transaction coordinator as 
an initial phase by reducing functionality 
and pushing code changes to the 
manufacturer of the OCSP responder. 


Two OCSP Responder are required: one 
that re-signs responses, one that forwards 
signed responses without re-signing. 


Allows the basic seciirity infrastructure to 
be put in place and tested. 


No authorization checks are performed. 
Signatures are verified by the OCSP 
Responder but there are no checks 
performed to determine whether or not tlie 
request is from an authorized customer. 




There are no OCSP checks performed to 
deteraiine if a requestor's certificate has 
been revoked. 




All certificates in a requestor' s/responder's 
chain must be sent with the request/ 
response in order for the OCSP Responder 
to verify the signatures. This significantly 
increases the size of the messages. 




The RC must send individual requests to the 
RP - multiple certificate statuses caxmot be 
requested in the same message if they need 
to be processed by different OCSP 
responders. 




Not enough information is maintained in the 
iv^^^ xujL ixoii— icpuuiciiiuii puxposes. il is nox 
clear whether enough information about the 
requestor is retained for billing purposes. 




Can only perform certification status 
checks. Will still require a transaction 
coordinator to fulfill other services. 




Will not provide generic reusable core 
components. 
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Pros 


Cons 




The IETF OCSP Responder specification 
does not require Responder to provide this 
additional functionality. 



Technical and security requirements for OCSP responder 204 are preferably 
5 specified by root entity 110. An exemplary set of requirements is described below. 
Technical Requirements 

In a preferred embodiment, each OCSP responder 204 operates pursuant to the Online 
Certificate Status Protocol (OCSP). 

In a preferred embodiment, when an OCSP responder 204 receives an OCSP request, 

10 it validates the requestor's certificate, authenticates the requestor, and verifies that the 
requestor is a contracted system user with the participant that received the request by 
performing a local status check on the requestor's certificate. Authentication of the requestor 
may be accomplished using the signed OCSP request, in the case of an inter-institution 
request, or through secure socket layers client authentication, in the case of a ciistomer 

1 5 request In addition, secure socket layers may be reqiiired to ensure the confidentiality of all 
requests. 

In a preferred embodiment, each OCSP responder 204 selects peer servers when 
making inter-institution requests based on a locator extension of the requested service and a 
local table. In an altemative embodiment, this information may be obtained by lightweight 
20 directory access protocol (LDAP) look up. 

In a preferred embodiment, each OCSP responder 204 may cache certificates subject 
to rules specified by root entity 110. 

In a preferred embodiment, each OCSP responder 204 verifies that inter-institution 
responses have been signed by an authorized responder certificate. For inter-institution 
25 OCSP requests, the OCSP responder of the relying participant 204 preferably re-signs the 
response firom, e.g., issuing participant 102 before transmitting it to the requestor. 

In a preferred embodiment, each OCSP responder supports the following responses: 
"revoked " "good," and "unknown." If a client OCSP responder receives a "revoked" 
response regarding a particular certificate produced at a time t, then the client OCSP 
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responder assumes that that certificate, or some certificate in the certificate chain of that 
certificate was revoked prior to time t. As such, the cKent OCSP responder does not possess 
sufficient evidence to transfer liability for documents that have been digitally signed after 
time t using the private key corresponding to the checked certificate to the server OCSP 
responder. 

If a client OCSP responder receives a "good" response regarding a particular 
certificate, produced at a time t, then the client OCSP responder assumes that that certificate 
and every other certificate in its certificate chain was m good standing at time t. As such, the 
client OCSP responder has sufficient evidence to transfer liability for documents that have 
been digitally signed prior to time t to the server OCSP responder. 

If the client OCSP responder receives an "unknown" response regarding a particular 
certificate produced at time t, then the client OCSP responder assumes that that certificate, or 
a certificate in the certificate chain of that certificate, is not known to be in good standing. 
As such, the client OCSP responder does not possess sufficient evidence to transfer liability 
for documents that have been digitaUy signed using the private key correspondmg to the 
checked certificate to the server OCSP responder. 
Security Requirements 

In a preferred embodiment, each OCSP responder 204 stores its private keys in a 
hardware security module that meets requirements established by root entity 110. 

In a preferred embodiment, each OCSP responder 204 uses separate keys for server 
secure socket layers, client secure socket layers, and OCSP responses. 

In a preferred embodiment, each OCSP responder 204 has the ability to operate on 
institution-hardened platform configurations. An institution-hardened platform is a tried and 
tested platform that is approved for use within an institution's firewall. 

In a preferred embodfanent, each OCSP responder 204 maintains detailed logs of all 
signed requests and responses, all exceptions or errors, and ail administrative and 
configuration actions. 

In a preferred embodiment, each OCSP responder 204 uses strong authentication, 
such as secure socket layers client authentication, to authenticate entities for all 
administrative transactions. 
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In a preferred embodiment, each OCSP responder 204 meets minimum security 
requirements established by root entity 110. In addition, the institution that maintains the 
OCSP responder may specify additional OCSP responder security rules. 

In a preferred embodiment, each OCSP responder 204 is configured to be highly 
available and deployable in a replicated mode. In addition, each OCSP Responder preferably 
responds to all requests in less than one second. 

OCSP responders are not typically required to perform checks on utility certificates. 
They may, however, be configured to allow a requestor unauthenticated access to the status 
of a utility certificate. 

In a preferred embodiment, an OCSP responder may be required to serve as an 
axithenticated interface to an institution's repository. Implementation details of this preferred 
embodiment may be left to the entity that maintains the OCSP responder. 

In a preferred embodiment, each OCSP Responder comprises additional interfaces to 
support additional fimctionality. In particular, each OCSP responder preferably comprises an 
additional interface to make mformation available to support a participant's customer-service 
requirements. In addition, each OCSP responder preferably comprises an institution-defined 
standard interface for exporting system and event logs. Each OCSP responder may also 
comprise an interface for export of information for billing applications. Billing data may be 
exported in any format including logs but preferably enables the requestor to determine the 
type and volume of the request. 

In a preferred embodiment, participants 102, 104 shown in Fig. 1 are referred to as 
level-one participants because they are issued digital certificates directly by root entity 110. 
Accordingly, the certificate chain of each participant begins at root entity 110. Each level 
one participant relies on root entity 1 10 to obtain the status of certificates of other level-one 
participants. 

In a fiirther preferred embodiment, the present system may comprise additional 
participants, called level-two participants. Each level-two participant is preferably issued a 
digital certificate by a level-one participant with which it is associated- These level-two 
participants may then serve as certificate authorities for tiieir respective customers and 
provide system services to those customers. 
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its configviration baseline document in the following three locations: (1) at the same physical 
location of the level one certification authority thereby allowing operational changes to be 
recorded as they occur; (2) at a secure location outside the physical location of the level one 
certification authority but in a controlled container; and (3) at an ofiTsite location with the 
5 level one certification authority's backup and archive records. In addition, each level one 
participant preferably provides a copy of its configuration baseline to root entity 110. 

In a preferred embodiment, level two participants also maintain a true and accurate 
record of the hardware and software configuration of their certification authority architecture. 
Each level two participant prepares, retains, and maintains at least three copies of its 

10 configuration document in the following three locations: (1) at the same physical location as 
the level two certification authority thereby allov^ng operational changes to be recorded as 
they occur; (2) at a secure location outside flie physical location of the level two certification 
authority but in a controlled container, and (3) at an ofiF-site location with the level two 
certification authority's back up and archive records. In addition, each level two participant 

15 preferably provides a copy of its configuration baseline to its sponsoring level one 
certification authority. 

Forms may be provided to facilitate documentation of hardware and software 
configurations. In a preferred embodiment, the hardware and software configurations of root 
entity 1 lO's and each participant's certification authority directory, OCSP responder, and 

20 Internet firewall are also documented. 

In a preferred embodiment, root entity 110 has primary responsibility for 
configuration management on a system-wide level. This responsibility is typically delegated 
to an officer of root entity 110, such as the Vice President of Operations. Each certificate 
authority preferably comprises a technical operations staff which has the operational 

25 responsibility for maintaining an accurate record of the certification authority's hardware and 
software configuration. 

In a preferred embodiment, the initial configuration baseline of each certificate 
authority is produced by commissioning the configuration baselines of each subordinate 
certification authority. 

30 In a preferred embodiment, a configuration change must comply with the following 

criteria: (1) a configuration change must be required to address a defined system 
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requirement; (2) a configuration change must be recommended by the certification 
authority's operations staff; (3) a configuration change to the operational platforms must be 
approved by an officer, such as the Vice President of Opemtions in the case of the root 
entity, and a senior manager accountable for the integrity of the certification authority, in the 
case of a level one or level two certification authority; (4) notice of configuration changes 
must be given to any affected parties; (5) a configuration change must take into account 
relevant configuration change criteria imposed by governmental or standards setting bodies; 
and (6) a configm-ation change must be recorded by setting out the date of the change and the 
period of each previous configuration. Each certificate authority typically archives 
configuration changes with other archived materials such as backup tapes. 

In a preferred embodiment, the configuration baseline is implemented in conjunction 
with the root entity's system security policy and is an audited component of each certification 
authority. 

While the invention has been described in conjunction with specific embodiments, it 
is evident that numerous alternatives, modifications, and variations will be apparent to those 
skilled in the art in light of the foregoing description. 
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Claims ; 

1 . A transaction processing system comprising: 
a logging component; 

a billing component; 
5 a signing component; 

at least one of: a warranty service, a certificate status check service, or a payment 
guarantee service; and 

a transaction processing monitor for combining operations of the components and at 
least one service into one or more transactions; 
10 the one or more transactions having flie properties of atonicity , consistency, isolation 

and durability. 

2. A secure method for conducting certificate status checks over an electronic network 
comprising at least one electronic network, at least one subscribing customer, at least one 

1 5 relying customer, at least one issuing participant, at least one relying participant, and at least 
one root, said method comprising the steps of: 

(a) issuing a smart to said at least one subscribing customer; said subscribing 
customer sending data to be signed to the smart card; and the smart card 

20 generating a signature and returning the signature along with the subscribing 

customer's certificate and the issuing participant's certificate; 

(b) sending the signed data, the subscribing customer's certificate, and the issuing 
participant's certificate to said at least one relying customer; said at least one 

25 relying customer verifying the signature on the signed data and creating an 

OCSP request containing the subscribing customer's certificate and the issuing 
participant's certificate; and the online certificate protocol request containing 
the subscribing customer's certificate and the issuing peuticipant's certificate 
being sent to a hardware security module for signature; and the hardware 

30 security module returning a signature and the relying customer's certificate; 
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(c) sending the OCSP request containing the subscribing customer's and the 
issuing participant's certificates to the relying participant's transaction 
coordinator, along with the relying customer's certificate; and 

the relying participant's transaction coordinator checking a customer database to 
make sure that the request was signed by an existing relying customer before 
processing the request; and 



the relying participant's transaction coordinator storing raw transaction data into a 
raw transaction log and storing billing data in a billing log; and the relying 
participant's transaction coordinator verifying the relying customer's signature on 
the service request using the relying customer's certificate, which was sent with the 
service request, and 



the relying participant's certificate and the root pubUc key, both of which art 
stored in its hardware security module; and 

the relying participant's transaction coordinator generating an OCSP request 
containing the relying customer's certificate, signing it, and sending it to a 
co-located OCSP responder; and 



the OCSP responder verifying the relying customer's signature on the request, 
checking its local repository, and sending a response back to the relying 
participant's transaction coordinator and 

the relying participant's OCSP responder generating a request for the subscribing 
customer's certificate, signing it and sending it to the issuing participant along with 
the relying participant's certificate; 

(d) receiving said request for the subscribing customers certificate by the issuing 
participant's transaction coordinator; and 
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log; and 

theroot'stransactioncoordinatorverifyingthe signatures 
sending the request to its OCSP responder, and 

theroot'sOCSPrespondercheclcingitslocalrepositoryandsendingaresponse 
back to root's transaction coordinator; and 
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the root's transaction cooidinator sending a signed response to said issuing 
participant's transaction coordinator; 

(f) receiving the response by the issuing participant's transaction coordinator, the 
issuing participant's transaction coordinator storing the response its raw 
transaction log for non-repudiation purposes; and 

the issuing participant's transaction coordinator generating an OCSP request from 
the request it received containing the subscribmg customer's certificate, signing it, 
and sending it to the issuing participant's OCSP responder along with its own 
certificate; and 

the issuing participant's OCSP responder verifying the signature on the request, 
generating a response, signing it, and returning the signed response to said issuing 
participant's transaction coordinator; and 

the issuing participant's transaction coordinator verifying 1iie OCSP responder's 
signature, resigning the response, and returning it to the relying participant's 
transaction coordinator along with its own certificate; 

(g) receiving a response by the relying participant's transac^on coordinator, the 

relymg participant's transaction coordinator storing the raw response data in its 
raw transaction log for non-repudiation purposes; and 

the relying participant's transaction coordinator verifying the signature on the 
response using the issuing participant transaction coordinator's certificate and the 
root public key, which is stored in its hardware security module; and 

the relying participant's transaction coordinator generating an OCSP request for the 
issuing participant's certificate and sending it to the root's transaction coordinator. 
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(h) receiving a request by the root's transaction coordinator, the root's transaction 
coordinator storing the raw request data in its raw transaction log and storing 
the billing data in its billing log; and 

5 the root's transaction coordinator verifying the signature on the request; and 

the root's transaction coordinator sending the request to its OCSP responder;. and 

the root's OCSP responder checking its local repository and sending a response 
1 0 back to the root's transaction coordinator; and 

the root's transaction coordinator sending the response to the relying participant's 
transaction coordinator; 

15 (i) receiving the response by the relying participant's transaction coordinator, the 

relying participant's transaction coordinator storing the response in its raw 
transaction log for non-repudiation purposes; and 

the relying participant's transaction coordinator generating a isigned online 
20 certificate service protocol request for the issuing participant's certificate and 

sending it to the root's transaction coordinator; 

(]) receiving the request by the root's transaction coordinator, the root's 

transaction coordinator storing the raw request data in its raw transaction log; 
25 and 

the root's transaction coordinator storing the relevant billing data in its billing log; 
and 

30 the root's transaction coordinator verifying the signature on the request and 

sending the request to its OCSP responder; and 
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the root's OCSP responder checking its local repository and sending a response 
back to the root's transaction coordinator; and 

the root's transaction coordinator sending a signed response to the relying 
participant's transaction coordinator; 

(k) receiving the response by the relying participant's transaction coordinator, said 
relying participant's transaction coordinator storing the response in its raw 
transaction log for non-repudiation purposes; and 

the relying participant's transaction coordinator generating an OCSP response from 
the responses received from the issuing participant's transaction coordinator, 
signing it, and sending it to relying customer along with the relying participant's 
certificate; 

(1) receiving the response by the relying customer; the relying customer verifying 
tiie response using the root's public key certificate stored in its hardware 
security module; and 

the relying customer sending a request for the relying participant's certificate in 
order to determine if the certificate has been revoked; 

(m) receiving the request by the relying participant's transaction coordinator, the 
relying participant's transaction coordinator verifying the signature on the 
request and sending a request to its local OCSP responder to ensure that the 
relying customer's certificate has not been revoked; and 

the relying participant's local OCSP responder sending a response back to the 
relying participant's transaction coordinator; and 
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the relying participant's transaction coordinator sending a request on the relying 
participant's certificate to the root's transaction coordinator; 

(n) receiving the request by the root's transaction coordinator, the root's 

transaction coordinator verifying the signature on the request and checking with 
its local OCSP responder to determine the status of the relying participant's 
certificate; and 

the root's transaction coordinator forwarding the response received from its local 
OCSP responder to the relying participant's transaction coordinator; 

(o) receiving the response by the reljdng participant's transaction coordinator and 
the relying participant's transaction coordinator forwarding the response to the 
relying customer; 

(p) receiving the response by the relying customer, the relying customer providing 
acknowledgment to the subscribing customer. 

3. A system for providing one or more services via a network, comprising: 

a root entity, the root entity operating a root entity certification authority, the root 
entity maintaining a root entity configuration baseline for the root entity certification 
authority, the root entity configuration baseline comprising the operating environment 
of the root entity certification authority; 

at least one level participant, the level-one participant operating a level-one 
certification authority, the level-one participant maintaining a configuration baseline 
for the level-one certification authority, the configuration baseline for the level-one 
certification authority comprising the operating environment of the level-one 
certification authority; 
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at least one level-two participant, the level-two participant operating a level-two 
certification authority, the level-two participant maintaining a configuration baseline 
for the level-two certification authority, the configuration baseline for the level-two 
certification authority comprising the operating environment of the level-two 
5 certification authority, 

4. The system of claim 3, wherein the configuration baseline of each entity's 
certification authority is recorded on a form. 

^ 0 5. The system of claim 3, wherein a copy of each entity's configuration baseline is 
maintained by the root entity. 

6. The system of claim 3, fiirther comprising a configuration manager, the configuration 
manager bemg an officer of the root entity, the configuration manager further having primary 

1 5 responsibility for configuration management within the system. 

7. The system of claim 3, wherein each certification authority comprises a technical 
operations staff, the technical operations staff having primary responsibility for maintaining 
record of an entity certification authority's configuration. 

20 . 

8- The system of claim 3, wherein the configuration baseline for each entity's 
certification authority is maintained at the same physical location of the entity's certification 
authority, 

25 9. The system of claim 3, wherein the configuration baseline for each entity's 

certification authority is maintained at a secure location outside the physical location of the 
entity's certification authority. 

10. The system of claim 3, wherein the configuration baseline for each entity's 
30 certification authority is maintained at an ofiFsite location. 
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1 1 . The system of claim 3, wherein changes to the configiaration baseline of an entity's 
certification authority are made to address a system requirement. 



12. The system of claim 3, wherein an affected party is notified of a change to the 
5 configuration baseline of an entity's certification authority. 

1 3 . The system of claim 3, wherein a change to the configuration baseline of an entity's 
certification authority takes into account configuration change criteria imposed by 
govenmient bodies. 

10 

14. The system of claim 3, wherein a change to the configuration baseline of an entity's 
certification authority takes into account configuration change criteria imposed by standards- 
setting bodies. 

15 15- A system for providing a certificate status check service via a network comprising a 
plur£ility of entities including at least one root entity, at least one issuing participant, and at 
least one relying participant, each entity comprising: 

a transaction coordinator; 

20 

an online certificate status protocol responder, the online certificate status protocol 
responder checking status of a certificate, the online certificate status protocol 
responder receiving online certificate status requests fi:om the transaction coordinator, 
the online certificate status protocol responder sending online certificate status 
25 responses to the transaction coordinator; and 

at least one hardware security module. 

1 6. The system of claim 1 5, wherein the online certificate status protocol responder sends 
30 a revoked response regarding a checked certificate, the revoked response indicating that the 
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certificate, or a certificate in a certificate chain of the certificate, has been revoked prior to a 
particular time. 



1 7. The system of claim 1 6, wherein the issuing participant does not accept liability for 
5 documents that have been signed after the particular time using a private key coirespondmg 

to the checked certificate. 

1 8. The system of claim 1 5, wherein the online certificate status protocol responder sends 
a good response regarding a checked certificate, the good response indicating that the 

1 0 certificate and every other certificate in the certificate chain of the certificate is in good 
standing at a particular time. 

1 9. The system of claim 1 8, wherein the issuing participant accepts liability for 
documents that have been signed prior to the particular time using a private key 

1 5 corresponding to the checked certificate. 

20. The system of claim 1 5, wherein the online certificate status protocol responder sends 
an unknown response regarding a certificate, the unknown response indicating that the 
certificate, or a certificate in the certificate chain of the certificate, is not known to be in good 

20 standing at a particular time. 

21 . The system of claim 20, wherein flie issuing participant does not accept liability for 
documents that have been signed prior to the particular time using a private key 
corresponding to the checked certificate. 

25 

22. The system of claim 15, wherein the online ceatificate status protocol responder stores 
its private keys in a hardware security module. 

23- The system of claim 15, 'wherein the online certificate status protocol responder meets 
30 a set of minimum security requirements established by the root entity. 
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24. In a system comprising a first participant, a second participant, a first customer, and a 
second customer, the first customer being a customer of the first participant, the second 
customer being a customer of the second participant, each entity being provided with a 
digital certificate and an associated private key, a method for validating a certificate 
comprising: 

a) the first customer signing data with its private key; 



10 



b) the first customer transmitting the signed data to the second customer; 

c) the second customer generating a validation request for the first customer's certificate; 



15 



20 



25 



d) the second customer transmitting flie validation request for the first customer's certificate 
to the second participant; 

e) the second participant forwarding the validation request to the first participant; 

f) the first participant transmitting a response to the validation request to the second 
participant; and 

g) the second participant transmitting the response to the second customer. 

25. The method of claim 24, wherein the second customer uses a hardware security module 
to sign the validation request 

26. The method of claim 24, wherein each participant stores data relating to the validation 
request for non-repudiation. 



27. The method of claim 24, wherein each participant stores data relating to the validation 
30 request for billing. 
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28. The method of claun 24, wherein each participant checks a customer database to verify 
that the validation request was received from an authorized entity before processing the 
request. 

5 29. The method of claim 24, wherein each participant uses an online certificate status 
protocol responder to generate the validation request. 

30. In a system comprising a first participant, a second participant, a first customer, and a 
second customer, the furst customer being a customer of the first participant, the second 
10 customer being a customer of the second participant, each entity being provided with a 

digital certificate and an associated private key, a method for providing a warranty service 
comprising: 



15 



a) the first customer signing data with its private key; 

b) the first customer transmitting the signed data and its certificate to the second customer; 

c) the second customer generating a warranty request for the first customer's certificate; 
20 d) the second customer transmitting the warranty request to the second participant; 

e) the second participant forwarding the warranty request to the first participant; 

f) the first participant determining whether or not to issue a warranty; 

25 

g) the first participant transmittmg the determination to the second participant; and 

h) the second participant transmitting the determination to the second customer. 

30 31. The method of claim 30, wherein the second customer uses a hardware security module 
to sign the warranty request. 
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32. The method of claim 30, wherein each participant stores data relating to the warranty 
request for non-repudiation. 

33. The method of claim 30, wherein each participant stores data relating to the warranty 
5 request for billing. 

34. The method of claim, 30 wherein each participant checks a customer database to verify 
that a request was received jfrom an authorized entity before processing the request. 

1 0 35. In a system comprising a root entity, a first participant, a second participant, a first 

customer, and a second customer, the first customer being a customer of the first participant, 
the second customer being a customer of the second participant, each entity being provided 
with a digital certificate and an associated private key, a method for validating a certificate 
comprising: 

15 

a) the second customer generating an validation request containing the second participant's 
certificate; 

b) tiie second customer transmitting the validation request containing the second 
20 participant's certificate to the second participant; 

c) the second participant generating a validation request for the second participant's 
certificate; 

25 d) the second participant transmitting the validation request containing the second 
participant's certificate to the root entity; 

e) the root entity transmitting a response to the validation request to the second participant; 
and 

30 

f) the second participant transmitting the response to the second customer. 
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36. The method of claim 35 wherein the second participant uses an online certificate status 
protocol responder to generate the validation request. 
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